Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Quality of service in an IP crypto partitioned network

VIEWS: 8 PAGES: 7

									                                                                                                                               Télécommunications




Quality of service in an IP crypto partitioned network
par Rob Goode(1), Patrice Guivarch(2), Mark Stell(3)




Cet article a été publié au MILCOM en octobre 2002.
Les réseaux de télécommunications militaires utilisent massivement le protocole IP (Internet Protocol). Afin de sécuriser ces réseaux, la méthode la
plus répandue consiste à utiliser des chiffreurs IP. Mais l’utilisation de chiffeurs IP a pour conséquence de partitionner un réseau en deux parties qui
s’ignorent : d’une part les enclaves protégées par les chiffreurs, d’autre part le reste du réseau.
Cet article présente, dans un premier temps, le principe de fonctionnement des chiffreurs IP. Il décrit ensuite les problèmes posés pour offrir une qualité
de service de bout en bout dans une architecture comprenant des chiffreurs IP. Enfin les solutions retenues dans le projet international INSC
(Interoperable Networks for Secure Communications) et dans le réseau de la marine américaine sont exposées.

It is planned that military grade IP crypto devices (ICD) will be increasingly deployed in defence networks. The ICDs are used to partition the network
into clear text higher classification areas (“Red”) and enciphered lower classification areas (“Black”), where the Black area may be implemented as
an IP network of arbitrary complexity. We refer to this architecture as an IP crypto partitioned network (ICPN).
When there is a need to prioritise critical or real-time traffic flows over other flows in an IP network, IP Quality of Service (QoS) may be required.        23
Provision of end-to-end (QoS) across an ICPN is a balance between, on the one hand, the deliberate information hiding used to ensure data confiden-




                                                                                                                                                              RSTD 64 - Juin 2004
tiality, and on the other hand the need to signal QoS information across the Red/Black partition boundaries.
This paper introduces IP QoS models and discusses their applicability to an ICPN. The relevant differences between ICDs and link level crypto devices
are summarised. Aspects of an ICPN affecting end-to-end QoS are highlighted. Deployment experience with ICPN in the US Navy is described, as is the
QoS architecture planned for the Interoperable Networks for Secure Communications project. Suggestions are given for design decisions and open
issues are recorded. It is concluded that whilst end-to-end QoS is possible, a number of open issues remain.




   M
          ost IP networks offer a single class of service                          The introduction of IP cryptos into the network has
          called "best effort", which means that the                            an impact on both the operation and the management
          network will do its best to deliver the packet                        of IP Qos, due mainly (but not only) to the intentional
and all packets are treated equally. In military networks                       partitioning of the network into Red and Black parts.
there may be a requirement for multi-level priority and                         The partitioning makes it difficult for all the network
pre-emption, as discussed in [1, 2]. Additionally some                          devices to operate in concert to achieve end-to-end Qos.
applications may require specific network performance.
A real time application like voice, for instance, requires
a short and constant packet delay. This means that                              IP quality of service models
some packets should have a higher claim on network
resources than other packets. An IP network that                                   There are two significant models for the provision of
supports these multiple classes of service is referred to                       IP Qos, the Integrated Service (IntServ) model [3] and
as offering Quality of Service (Qos). There are two                             the Differentiated Services (DiffServ) model [4].
models for IP Qos, called Integrated Services and                               IntServ uses a protocol (usually the Resource
Differentiated Services, described later in this paper.                         Reservation Protocol, RSVP [5]) to dynamically request


  (1) NATO Consultation, Command and Control Agency – The Hague, The Netherlands
  (2) CELAR Bruz, France
  (3) Space and Naval Warfare System Center – San Diego, CA, USA
             Télécommunications

                      the reservation of network resources for a specified flow    Internet Control Message Protocol (ICMP) and the
                      of packets. RSVP messages are sent hop by hop between        Domain Name System (DNS). An Internet will also run
                      RSVP-capable routers. RSVP can request either a              unicast routing protocols such as Routing Information
                      Guaranteed Service (guaranteed bandwidth and delay           Protocol (RIP) and Open Shortest Path First (OSPF).
                      bounds) or a Controlled Load Service which tries to          Multicast routing protocols might also be used.
                      emulate a lightly loaded network. A successful request       Partitioning the network with ICDs is likely to mean
                      means that the resources have been reserved, otherwise       that none of the protocols mentioned can be operated
                      the request will be unsuccessful.                            between Red devices and Black devices.

                         The Differentiated Services model marks packets              An ICD may include the functionality to copy some
                      with a label called the DiffServ Code Point (DSCP),          values from the Red side packet IP header into the
                      which is used to indicate the "forwarding class" to be       Black side encapsulating IP header, such that the value
                      used for that packet. The bandwidth allocation and           is visible to Black side devices. Where this functionality
                      "drop priority" for each forwarding class is configured      is present, a security policy will determine which values
                      out-of-band. The drop priority provides a mechanism          may be copied and which may not. In an equivalent
                      for pre-emption under congestion conditions. Since the       manner, the ICD might offer the functionality to copy
                      DiffServ model does not use a protocol (such as RSVP)        some values from the encapsulating Black side IP
                      to dynamically check the availability of network             header into the recovered Red side IP header after de-
                      resources, they may not be available when required due       encyption, which would overwrite the original values in
                      to over-subscription, congestion, network failure etc.       these fields. The security policy would determine
                                                                                   whether such functionality, if present, was used.
                         The DSCP field is present in both IPv4 and IPv6. In
                      IPv4, this field supersedes the Type of Service (TOS)           Most defence networks today are secured by link
                      field. IPv6 also includes a 20-bit flow label field in the   layer crypto devices (LLCDs), which operate at layer
                      IP header which can be used for Qos purposes,                two in the OSI seven layer model. The operation of
                      although no standard exists for such use to date.            LLCDs is compared to that of ICDs in Table 1.

                                                                                      Functional aspects LLCD ICD Connectivity options
                      Functional aspects of IP crypto devices                      point to point link IP network Link layer protocol dedi-
                                                                                   cated any Network layer protocol any dedicated to
24                       IP Crypto Devices (ICDs) operate at layer three of
                      the OSI seven layer model, the network layer, and speci-
RSTD 64 - Juin 2004




                      fically the IP network protocol. This means that they
                      interact directly with other network layer devices, but
                      do not interpret protocols higher than the network
                      layer. ICD may operate in transport mode, where only
                      the data payload is encrypted, or in tunnel mode where
                      the whole packet is encrypted and then encapsulated as
                      the payload of a new packet. In this document the ICD
                      is assumed to be operating in tunnel mode. Transport
                      mode is not considered further.

                         Packets received on the Red side of the ICD are
                      encrypted, encapsulated into a new IP packet, and
                      forwarded to the Black side. Valid packets received on
                      the Black side of the ICD are de-encapsulated, decryp-
                      ted, and forwarded to the Red side. The protocol infor-
                      mation in packets generated by devices on the Red side
                      of the ICD is hidden from devices on the Black side of
                      the ICD by encryption. Thus it is not possible to run a
                      higher layer protocol between a Red side device and a
                      Black side device. The ICD partitions the network into
                      Red and Black, an ICPN.

                        Networks running the Internet Protocol usually run a
                      number of other protocols (utility protocols) to form a
                      functional Internet. These utility protocols include the
                                                                                   Table 1. Comparison of ICD and LLCD.
                                                                                                   Télécommunications

IP Deployment extensive limited Peering one peer many            The ICD will delay packets that transit it. The size of
peers Traffic load constant only when data is being sent      the delay may be constant under all conditions, or may
Traffic analysis difficult possible Throughput rate           vary according to some combination of factors such as:
constant may be variable Packet delay constant may be         packet size; source or destination address; packet rate;
variable Data overhead constant may be variable               packet type; ICD housekeeping tasks such as keying,
Intentional Drop none security policy, congestion.            logging, task scheduling etc.; internal queue conditions.
   It can be seen from Table 1 that the use of ICDs
enables traffic to be routed over IP networks, and to            The DSCP value is exposed to the Black network,
minimise bandwidth usage. It is also apparent that            but the source and destination addresses, the port
networks with ICD’s are more complex to architect             number, and the protocol type are hidden. This means
than ones with LLCD’s, if Qos is required.                    that any Qos techniques which rely on identifying indi-
                                                              vidual flows within forwarding classes may not be appli-
                                                              cable in the Black network. An example of such a
Issues in achieving IP QoS                                    technique is Weighted Random Early Detection
and in an IP crypto partitioned network                       (WRED) which identifies those high bandwidth flows
                                                              which would respond to back pressure (e.g TCP but not
   The IntServ model relies on the use of a resource reser-   UDP) and starts to drop packets before full congestion
vation step, which can be performed using RSVP or by          is experienced, thus reducing the risk of uncontrolled
some other means. The RSVP protocol can be run inde-          packet drop. Non standard coding of DSCP values
pendently on the Red and the Black sides of the ICD,          could be used to recreate flow information (for instance
but as discussed earlier it cannot be run between Red side    see [6]), so long as this exposure of flow is allowed by
devices and Black side devices in a partitioned network.      the security policy.

   The DiffServ model does not include a dynamic                  The ICD will discard some packets for specific
signalling protocol, instead the DSCP field in the            reasons that might include: queue overflow; disallowed
packet header is used to allocate packets to forwarding       source or destination addresses; disallowed packet type;
classes. In the discussion on the functionality of ICDs it    expired time-to-live value; tampered Black side packets;
was noted that the possibility exists to copy one or          unencrypted Black side packets. Queue overflow may
more values from the Red side IP packet header into the       occur either if the ICD cannot process packets at the
Black side encapsulating IP header. A pertinent applica-      received data rate, or if the throughput on one interface
tion of this approach is to copy the DSCP value from          is slower than on the other one.                              25
the Red side packet to the encapsulating Black side




                                                                                                                            RSTD 64 - Juin 2004
packet. Hence the Black network can be informed                  If the ICD does not perform internal Qos queuing
which forwarding class should be used for each packet,        strategies based on the values in the packet header then
even in the partitioned network.                              packets will (probably) be processed in order of arrival.
                                                              This means that a small high-priority packet which
   Subsequent discussions will assume that the DiffServ       arrives just after a large low-priority packet will be
approach is used, that the ICD copies the Red side            delayed until the large packet has been processed. This
DSCP value into the Black side encapsulating IP header,       may have a small effect where the link throughput is
and that the Black side DSCP value is discarded on            high and the ICD operates at near wire-speed, but can
decryption. This does not preclude the use of IntServ         have a more significant effect otherwise.
operating independently on either side of the ICD, but
that concept is not further discussed here.                      The inability to use ICMP across the partition boun-
                                                              dary means that PING and Traceroute cannot be used
   The ICD encrypts a Red packet and encapsulates it          for network diagnostic purposes between the Red and
in a Black IP packet. This means that a packet entering       Black domain, but can be used within each domain.
on the Red side will cause a larger packet to be forwar-      Path Maximum Transfer Unit (MTU) discovery based
ded on the Black side. This effective increase in packet      on setting the “Don’t Fragment” bit in the IPv4 packet
size is relevant to the provision of Qos, all other factors   header, and relying on an ICMP error message, will
being equal, for the following reasons:                       need to cope with the “black hole” caused by the fact
   – it decreases effective bandwidth ;                       that no ICMP error message will be received across a
   – it (minimally) increases latency ;                       security domain boundary.
   – for a mixed size packet streams it increases jitter
     (latency variation) ;                                       A congested router will, when its queues are full,
   – it may cause fragmentation which in turn will            discard packets. It is useful if, prior to buffer overflow,
     increase the overhead and hence affect latency and       the router can indicate to the sender that the packet rate
     jitter                                                   should be reduced or packets will be discarded. One
             Télécommunications

                      mechanism for achieving congestion notification that is          The placement of a Qos-aware network device on
                      being considered in the Internet community is Explicit       each side of an ICD can help if the ICD is not itself
                      Congestion Notification (ECN) [7]. In ECN the origi-         Qos-aware. Traffic shaping and rate limiting functiona-
                      nator sets a bit in the packet header to request notifica-   lity can be performed before the packets reach the ICD.
                      tion of congestion. A router that is experiencing            This means that high-priority packets can pre-empt
                      congestion will set another bit in the IP packet header,     lower priority ones, and the traffic can be rate limited
                      if requested, and when the destination host sees that        such that the ICD is not overloaded.
                      congestion is flagged it will request the sender to slow
                      down. The ECN mechanism would require that the                  If the ICD is sandwiched between routers for Qos
                      relevant bit in the IP packet header be copied from the      reasons, the Red side router can also be used to support
                      Black encapsulating packet into the recovered Red            the tunnelling of packets, for instance using Generic
                      packet following decryption. If this copying does not        Router Encapsulation (GRE), between Red side routers.
                      occur then ECN does not work.                                The advantage of GRE tunnels is that they can be used
                                                                                   to hide information, such as source and destination
                         The lack of a back pressure flow control mechanism        addresses or packet types, from the ICDs. This can
                      in an ICPN can be seen to be important in the case           simplify configuration of the ICD. For instance when
                      where the ICD has high speed interfaces (such as             the list of valid source addresses is set up in the ICD as
                      Ethernet) but the packets are then sent out over a slow      an access control list (ACL), it could potentially contain
                      speed link across a WAN to another ICD. If no mecha-         just one valid source address – that of the tunnel
                      nism is put in place to prevent it, hosts on the Red side    endpoint – rather than the list of all hosts on Red
                      of the ICD may attempt to send data at Ethernet              network. This is shown later in the description of the
                      throughput rates through the ICD, which will cause           U.S. Navy’s Automated Digital Network System. A
                      significant packet drop at the WAN ingress point.            second reason why information might be hidden from
                                                                                   the ICD could be to run IP Multicast through an ICD
                         One important aspect of providing end-to-end Qos is       that is not IP Multicast aware, as described in [9].
                      network monitoring and management. In order to
                      ensure that best use is made of network resources, and          It is possible to dynamically monitor the service
                      appropriate remedial action is taken when required, it is    levels being achieved between Red networks, and to
                      helpful to have an accurate and up-to-date view of the       use this information to dynamically reconfigure the
                      whole network. In an ICPN the network management             Red side traffic shaping so as to make best use of chan-
26                    of the Red domain must necessarily be separated from         ging traffic conditions. Equipment to perform this
                      that of the Black domain for security reasons. This          function exists, such as that produced by Ipanema
RSTD 64 - Juin 2004




                      makes unified network management difficult to achieve        Technologies [10].
                      (but see [8]).
                                                                                      In order to achieve a useful Qos-enabled network, it
                                                                                   is necessary to carefully select the set of service classes
                      Strategies for supporting IP Qos                             to be offered. For instance it may be required to sepa-
                      in an IP crypto partitioned network                          rate UDP classes from TCP, separate critical traffic from
                                                                                   non-critical traffic, separate traffic requiring low latency
                         A simple approach to achieving IP Qos is to use           from that which is delay-tolerant, separate loss-sensitive
                      physically separate ICDs for each class of service requi-    from loss-tolerant. It is possible for all these require-
                      red. If the network resources in the Black network are       ments to be orthogonal, and hence the mapping of
                      configured appropriately, and the network sized such         applications onto a small number of service classes can
                      that all the service levels can be achieved simulta-         be problematic. The provision of a large number of
                      neously at the expense of best effort traffic, then no       service classes, to reflect the diverse application require-
                      signalling across the ICD is required for Qos. In some       ments, runs the risk that managing the interaction
                      ICPNs this may be appropriate, but in the general case a     between flows in different service classes may become
                      more dynamic solution is required that can respond           too complex for network management.
                      intelligently to partial network failure or reconfigura-
                      tion, and uses fewer ICDs.                                      The use of well defined Service Level Specifications
                         If different packets sent through an ICD require          (SLS) at Red/Black boundary is a clear requirement
                      different Qos handling, then some signalling is required     when the network management is partitioned into Red
                      to inform the Black network of that. The signalling is       and Black domains. This approach is being adopted by
                      best achieved by following the DiffServ standard and         the Interoperable Networks for Secure Communications
                      configuring the ICD to copy the Red side DSCP field          project, as discussed later. It should be realised, howe-
                      into the encapsulating Black side IP header, assuming        ver, that the writing of Qos SLS is a relatively immature
                      that this is allowed by the security policy.                 discipline.
                                                                                                   Télécommunications

QOS architecture for Iinteroperable Network                   Deployment experience in the U.S. Navy
for Secure Communications
                                                                  The ability of a system of IP crypto devices (ICDs) to
   The Interoperable Networks for Secure                      scale to realistic military applications is dramatically
Communications (INSC) project [11] is an internatio-          affected by the choice of static versus automatic esta-
nal collaborative activity between eight NATO                 blishment of security tunnels. The U.S. Navy’s
nations. The objective of the INSC project is to study        Automated Digital Network System (ADNS) has
and demonstrate an interoperable, manageable and              deployed ICDs since 1994, and the primary device has
secure military network based on existing and emer-           been the Motorola Network Encryption System (NES).
ging standards.                                                   The NES requires static configuration of security
                                                              tunnels, which is labor intensive. Moreover, the confi-
   The INSC operational architecture consists of two          gurations are centrally administered and distributed to
different kinds of networks: transit networks and stub        remote sites. The U.S. operational fleet reported that
networks. A transit network acts as a service provider.       this scheme was not acceptable. The first problem was
Flows coming from a network (stub or transit) have to         the delay in adapting to changing network topology. It
conform to negotiated traffic profiles defined in             required up to several days to prepare and distribute a
Services Level Specifications (SLSs). The transit             new security tunnel (ST) database. The second problem
networks operate at the unclassified level (Black).           was that every NES in a battle group required a copy of
Attached to the transit networks are the stub networks        the new ST database, if any network behind any NES in
which are made up of network devices and computers            the battle group changed. The delay was unacceptable
running classified (Red) information services. Stub           to the fleet, and the growing ST database became
networks may be used for national needs or as part of a       increasing hard to manage. ADNS eventually managed
coalition. Data flows coming from stub networks are           this problem by using Generic Router Encapsulation
protected by an IP Crypto Device (ICD).                       (GRE) tunnels underneath the NES network. This is
                                                              illustrated in figure 2. Tunnelling in ADNS. However,
   In an operational scenario, several service classes are    an automated process for establishing security tunnels,
required to provide different levels of Qos (e.g. low-        or at least a method for distributed ST management,
delay and low-jitter services for telephony, priority         would be significantly more efficient than GRE tunnels,
service for military messaging, etc.). In order to meet the   and would be significantly more likely to scale well in
need for end-to-end Qos, and regardless of the Qos            military applications.
mechanisms used inside a network (e.g.: IntServ,                                                                            27
DiffServ, MPLS), the same level of Qos must be offered             Having a common rendezvous network for all ICDs




                                                                                                                            RSTD 64 - Juin 2004
all along the path. The INSC security policy specifies          should always be considered during the design of any
that no bypass is possible from Red side to Black side.         ICD-based system. The advantage of this scheme is that
Only mapping of the DSCP information from Red                   the ICD need only form an ST between the user, e.g., the
header to Black header is permitted. Depending on               ship, and the rendezvous network, and the user has
values of DSCP defined in a network by a provider, the          access to all other users connected to the rendezvous
mapping of the DSCP field can be direct, or the DSCP            network. This is an advantage according to METCALF’s
value can be replaced by an equivalent value. In any            Law, which says «The value of a network is equal to the
case this mapping must be done in accordance with the           square of the number of people who use it.» The disad-
SLSs defined between the two service providers. The             vantage of a common network is that traffic passes in
architecture is presented in figure 1 INSC Qos                  clear text on the rendezvous network. This means that
Architecture.                                                   anyone with access to the rendezvous network has poten-
                                                                                         tial access to the networks on
                                                                                         all the ships connected to it. A
                                                                                         more secure solution would be
                    SLA                    SLA                 SLA                       the ability to establish a ST to
                                                                                         every ICD that a user might
                                                  Unclassified           Classified      wish to communicate with.
       Classified             Unclassified
    Stub Network ICD Transit Network 1 Transit Network 2
                                                                 ICD Stub Network        However, if the ability to
           A                                                                  B          rapidly and easily form STs to
                                                                                         every other ICD is not
                                                                                         possible, then a common
       Initial DSCP                                                     Recover          rendezvous network can permit
                    Tunneling              DSCP                       Initial DSCP
                    with DSCP             mapping                                        simple, secure communications
                     mapping                                                             with all other members of the
Figure 1. INSC Qos Architecture.                                                         rendezvous network.
             Télécommunications


                                                                          GRE Tunnel


                                                                        Security Tunnel

                                       UNCLAS                   SECRET             RF       SECRET          NES        UNCLAS
                                       Router
                                                      NES                         link      Router
                                                                Router                                                 Router



                                       UNCLAS                   SECRET                      SECRET                     UNCLAS
                                        LANs                     LANs                        LANs                       LANs
                                                      Ship                                               Shore
                      Figure 2. Tunnelling in ADNS.



                         The U.S. has a simple implementation of Qos to                 It is clear that a Qos enabled network must offer
                      support its ICD network. For example, UNCLAS                   more than one service class, it is less clear how many
                      networks on ships connect to a NES, and the NES                service classes should be offered. If only a few service
                      forwards the encrypted UNCLAS traffic to the SECRET            classes are offered then it may be difficult to map the
                      network on the ship. The SECRET router then                    application requirements onto the service classes offe-
                      connects the IP data systems to the ship-to-shore radio        red, which would essentially defeat the purpose of the
                      frequency (RF) links. The point of congestion is the           Qos enabled network. However if many service classes
                      interface from the SECRET router to the RF link. To            are offered, the architectural and network management
                      ensure that UNCLAS and SECRET traffic receive a fair           challenges can be significant. This is an area where more
                      share of the bandwidth, the Proteon Bandwidth                  deployment experience is required.
                      Reservation System (BRS) [12] is used on the SECRET               It is desirable to provide back-pressure on application
28                    router’s interface to the RF link. BRS guarantees a mini-      flows under congestion conditions, but it is not obvious
                      mum bandwidth to UNCLAS traffic and a minimum                  how the Black network can signal congestion conditions
RSTD 64 - Juin 2004




                      bandwidth to SECRET traffic. BRS also allows one               to the Red side other than by silently dropping packets.
                      enclave to dynamically «borrow» the bandwidth of the           A potential solution is to dynamically monitor the
                      other enclave, when it is available. If SECRET traffic is      service levels being achieved between Red networks,
                      not using all its guaranteed bandwidth, but UNCLAS             and to use this information to dynamically reconfigure
                      needs excess bandwidth, UNCLAS can borrow                      the Red side traffic shaping. This is an area where more
                      SECRET bandwidth until SECRET traffic needs the                deployment experience is required.
                      bandwidth. This scheme uses the source address of the
                      NES to classify traffic, as opposed to DSCP or TOS
                      markings. Traffic having the source address of the local       Conclusion
                      NES is sent to one BRS guaranteed bandwidth queue.
                      Traffic that does not originate from an NES is sent to           It has been shown how by using a suitable network
                      another guaranteed bandwidth queue. In this way,               design the benefits of IP Qos can be achieved in a
                      simple Qos guarantees (i.e., minimum bandwidth) are            network partitioned by IP cryptos. But there is currently
                      allocated to the traffic, some of which originates behind      insufficient deployment experience to determine
                      an ICD, and some of which doesn’t.                             whether the solutions proposed are robust and scalable.
                                                                                     There are still open issues in the areas of network mana-
                                                                                     gement, service class selection and congestion avoi-
                      Open issues                                                    dance. ✪

                         It has been noted that the provision of end-to-end          Aknowledgements
                      Qos requires unified network management, and that the             The authors would like to thank all those involved in
                      partitioning of the network management capability into         the INSC project [11], which has brought together tech-
                      Red and Black domains makes this difficult to achieve.         nical experts to study future military networking.
                                                                                                         Télécommunications

<Références>
[1] P. BLACKMORE, P. GEORGE, M. KWIATKOWSKI.                      [7] K. RAMAKRISHNAN, S. FLOYD, D. BLACK. "The
    "A Quality of Service Interface for Military Applications",       Addition of Explicit Congestion Notification (ECN) to IP".
    MILCOM 2000, USA, 2000.                                           RFC 3168, September 2001.

[2] J. Kingston. "Dynamic Precedence for Military IP              [8] S. SHYNE, H. MARKLE. "Managing Heterogenous
    Networks", MILCOM 2000, USA, 2000.                                Networks Across Security/Coalition Domains", MILCOM
                                                                      2000, USA, 2000.
[3] R. BRADEN, CLARK, S. SHENKER. "Integrated Services
    in the Internet Architecture: An Overview", RFC 1633,         [9] L. HIGGINS, G. MCDOWELL B. VONTOBEL. "Tunneling
    Internet Engineering Task Force, June 1994.                       Multicast Traffic Through Non-Multicast-Aware Networks
                                                                      and Encryption Devices". MILCOM 2001, USA, 2001.
[4] M. CARLSON, W. WEISS, S. BLAKE, Z. WANG,
    D. BLACK, E. DAVIES. "An Architecture for Differentiated      [10] Ipanema Technologies, http://www.ipanematech.com
    Services", RFC 2475, December 1998.
                                                                  [11] Interoperable Networks for Secure Communications
[5] R. BRADEN, L. ZHANG, S. BERSON, S. HERZOG,                         http://insc.nodeca.mil.no
    S. JAMIN. "Resource ReSerVation Protocol (RSVP),
    Version 1 Functional Specification", RFC 2205 Internet        [12] Proteon Bandwidth Reservation System. http://www.nxnet-
    Engineering Task Force, September 1997.                            works.com/Docs/lib56/sw_docs/or_56/qos/brs.htm#
                                                                       336
[6] L. ZHENG, L. ZHANG. "Modeling and Performance
    Analysis for IP Traffic with Multi-Class Qos in VPN",
    MILCOM 2000, USA, 2000.




                                                                                                                                   29




                                                                                                                                   RSTD 64 - Juin 2004

								
To top