tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4110


A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)

Part 4 of 4, p. 66 to 82
Prev RFC Part


prevText      Top      Up      ToC       Page 66 
5.  Interworking Interface

   This section describes interworking between different layer 3 VPN
   approaches.  This may occur either within a single SP network, or at
   an interface between SP networks.

5.1.  Interworking Function

   Figure 2.5 (see section 2.1.3) illustrates a case where one or more
   PE devices sits at the logical interface between two different layer
   3 VPN approaches.  With this approach the interworking function
   occurs at a PE device which participates in two or more layer 3 VPN
   approaches.  This might be physically located at the boundary between
   service providers, or might occur at the logical interface between
   different approaches within a service provider.

   With layer 3 VPNs, the PE devices are in general layer 3 routers, and
   are able to forward layer 3 packets on behalf of one or more private
   networks.  For example, it may be common for a PE device supporting
   layer 3 VPNs to contain multiple logical VFIs (sections 1, 2, 3.3.1,
   4.4.2) each of which supports forwarding and routing for a private

   The PE which implements an interworking function needs to participate
   in the normal manner in the operation of multiple approaches for
   supporting layer 3 VPNs.  This involves the functions discussed
   elsewhere in this document, such as VPN establishment and
   maintenance, VPN tunneling, routing for the VPNs, and QoS

   VPN establishment and maintenance information, as well as VPN routing
   information will need to be passed between VPN approaches.  This
   might involve passing of information between approaches as part of
   the interworking function.  Optionally this might involve manual
   configuration so that, for example, all of the participants in the
   VPN on one side of the interworking function considers the PE
   performing the interworking function to be the point to use to
   contact a large number of systems (comprising all systems supported
   by the VPN located on the other side of the interworking function).

5.2.  Interworking Interface

   Figure 2.6 (see section 2.1.3) illustrates a case where interworking
   is performed by use of tunnels between PE devices.  In this case each
   PE device participates in the operation of one layer 3 VPN approach.
   Interworking between approaches makes use of per-VPN tunnels set up
   between PE.  Each PEs operates as if it is a normal PEs, and
   considers each tunnel to be associated with a particular VPN.

Top      Up      ToC       Page 67 
   Information can then be transmitted over the interworking interface
   in the same manner that it is transmitted over a CE to PE interface.

   In some cases establishment of the interworking interfaces may
   require manual configuration, for example to allow each PE to
   determine which tunnels should be set up, and which private network
   is associated with each tunnel.

5.2.1.  Tunnels at the Interworking Interface

   In order to implement an interworking interface between two SP
   networks for supporting one or more PPVPN spanning both SP networks,
   a mechanism for exchanging customer data as well as associated
   control data (e.g., routing data) should be provided.

   Since PEs of SP networks to be interworked may only communicate over
   a network cloud, an appropriate tunnel established through the
   network cloud will be used for exchanging data associated with the
   PPVPN realized by interworked SP networks.

   In this way, each interworking tunnel is assigned to an associated
   layer 3 PE-based VPN; in other words, a tunnel is terminated by a VFI
   (associated with the PPVPN) in a PE device.  This scenario results in
   implementation of traffic isolation for PPVPNs supported by an
   Interworking Interface and spanning multiple SP networks (in each SP
   network, there is no restriction in applied technology for providing
   PPVPN so that both sides may adopt different technologies).  The way
   of the assignment of each tunnel for a PE-based VPN is specific to
   implementation technology used by the SP network that is
   inter-connected to the tunnel at the PE device.

   The identifier of layer 3 PE-based VPN at each end is meaningful only
   in the context of the specific technology of an SP network and need
   not be understood by another SP network interworking through the

   The following tunneling mechanisms may be used at the interworking
   interface.  Available tunneling mechanisms include (but are not
   limited to): GRE, IP-in-IP, IP over ATM, IP over FR, IPsec, and MPLS.

   o GRE

     The tunnels at interworking interface may be provided by GRE
     [RFC2784] with key and sequence number extensions [RFC2890].

Top      Up      ToC       Page 68 
   o IP-in-IP

     The tunnels at interworking interface may be provided by IP-in-IP
     [RFC2003] [RFC2473].

   o IP over ATM AAL5

     The tunnels at interworking interface may be provided by IP over
     ATM AAL5 [RFC2684] [RFC2685].

   o IP over FR

     The tunnels at interworking interface may be provided by IP over

   o IPsec

     The tunnels at interworking interface may be provided by IPsec
     [RFC2401] [RFC2402].

   o MPLS

     The tunnels at interworking interface may be provided by MPLS
     [RFC3031] [RFC3035].

5.3.  Support of Additional Services

   This subsection describes additional usages for supporting QoS/SLA,
   customer visible routing, and customer visible multicast routing, as
   services of layer 3 PE-based VPNs spanning multiple SP networks.

   o QoS/SLA

     QoS/SLA management mechanisms for GRE, IP-in-IP, IPsec, and MPLS
     tunnels were discussed in sections 4.3.6 and 4.5.  See these
     sections for details.  FR and ATM are capable of QoS guarantee.
     Thus, QoS/SLA may also be supported at the interworking interface.

   o Customer visible routing

     As described in section 3.3, customer visible routing enables the
     exchange of unicast routing information between customer sites
     using a routing protocol such as OSPF, IS-IS, RIP, and BGP-4.  On
     the interworking interface, routing packets, such as OSPF packets,
     are transmitted through a tunnel associated with a layer 3 PE-based
     VPN in the same manner as that for user data packets within the

Top      Up      ToC       Page 69 
   o Customer visible multicast routing

     Customer visible multicast routing enables the exchange of
     multicast routing information between customer sites using a
     routing protocol such as DVMRP and PIM.  On the interworking
     interface, multicast routing packets are transmitted through a
     tunnel associated with a layer 3 PE-based VPN in the same manner as
     that for user data packets within the VPN.  This enables a
     multicast tree construction within the layer 3 PE-based VPN.

5.4.  Scalability Discussion

   This subsection discusses scalability aspect of the interworking

   o Number of routing protocol instances

     In the interworking scenario discussed in this section, the number
     of routing protocol instances and that of layer 3 PE-based VPNs are
     the same.  However, the number of layer 3 PE-based VPNs in a PE
     device is limited due to resource amount and performance of the PE
     device.  Furthermore, each tunnel is expected to require some
     bandwidth, but total of the bandwidth is limited by the capacity of
     a PE device; thus, the number of the tunnels is limited by the
     capabilities of the PE.  This limit is not a critical drawback.

   o Performance of packet transmission

     The interworking scenario discussed in this section does not place
     any additional burden on tunneling technologies used at
     interworking interface.  Since performance of packet transmission
     depends on a tunneling technology applied, it should be carefully
     selected when provisioning interworking.  For example, IPsec places
     computational requirements for encryption/decryption.

6.  Security Considerations

   Security is one of the key requirements concerning VPNs.  In network
   environments, the term security currently covers many different
   aspects of which the most important from a networking perspective are
   shortly discussed hereafter.

   Note that the Provider-Provisioned VPN requirements document explains
   the different security requirements for Provider-Provisioned VPNs in
   more detail.

Top      Up      ToC       Page 70 
6.1.  System Security

   Like in every network environment, system security is the most
   important security aspect that must be enforced.  Care must be taken
   that no unauthorized party can gain access to the network elements
   that control the VPN functionality (e.g., PE and CE devices).

   As the VPN customers are making use of the shared SP's backbone, the
   SP must ensure the system security of its network elements and
   management systems.

6.2.  Access Control

   When a network or parts of a network are private, one of the
   requirements is that access to that network (part) must be restricted
   to a limited number of well-defined customers.  To accomplish this
   requirement, the responsible authority must control every possible
   access to the network.

   In the context of PE-based VPNs, the access points to a VPN must be
   limited to the interfaces that are known by the SP.

6.3.  Endpoint Authentication

   When one receives data from a certain entity, one would like to be
   sure of the identity of the sending party.  One would like to be sure
   that the sending entity is indeed whom he or she claims to be, and
   that the sending entity is authorized to reach a particular

   In the context of layer 3 PE-based VPNs, both the data received by
   the PEs from the customer sites via the SP network and destined for a
   customer site should be authenticated.

   Note that different methods for authentication exist.  In certain
   circumstances, identifying incoming packets with specific customer
   interfaces might be sufficient.  In other circumstances, (e.g., in
   temporary access (dial-in) scenarios), a preliminary authentication
   phase might be requested.  For example, when PPP is used.  Or
   alternatively, an authentication process might need to be present in
   every data packet transmitted (e.g., in remote access via IPsec).

   For layer 3 PE-based VPNs, VPN traffic is tunneled from PE to PE and
   the VPN tunnel endpoint will check the origin of the transmitted
   packet.  When MPLS is used for VPN tunneling, the tunnel endpoint

Top      Up      ToC       Page 71 
   checks whether the correct labels are used.  When IPsec is used for
   VPN tunneling, the tunnel endpoint can make use of the IPsec
   authentication mechanisms.

   In the context of layer 3 provider-provisioned CE-based VPNs, the
   endpoint authentication is enforced by the CE devices.

6.4.  Data Integrity

   When information is exchanged over a certain part of a network, one
   would like to be sure that the information that is received by the
   receiving party of the exchange is identical to the information that
   was sent by the sending party of the exchange.

   In the context of layer 3 PE-based VPNs, the SP assures the data
   integrity by ensuring the system security of every network element.
   Alternatively, explicit mechanisms may be implemented in the used
   tunneling technique (e.g., IPsec).

   In the context of layer 3 provider-provisioned CE-based VPNs, the
   underlying network that will tunnel the encapsulated packets will not
   always be of a trusted nature, and the CE devices that are
   responsible for the tunneling will also ensure the data integrity,
   e.g., by making use of the IPsec architecture.

6.5.  Confidentiality

   One would like that the information that is being sent from one party
   to another is not received and not readable by other parties.  With
   traffic flow confidentiality one would like that even the
   characteristics of the information sent is hidden from third parties.
   Data privacy is the confidentiality of the user data.

   In the context of PPVPNs, confidentiality is often seen as the basic
   service offered, as the functionalities of a private network are
   offered over a shared infrastructure.

   In the context of layer 3 PE-based VPNs, as the SP network (and more
   precisely the PE devices) participates in the routing and forwarding
   of the customer VPN data, it is the SP's responsibility to ensure
   confidentiality.  The technique used in PE-based VPN solutions is the
   ensuring of PE to PE data separation.  By implementing VFI's in the
   PE devices and by tunneling VPN packets through the shared network
   infrastructure between PE devices, the VPN data is always kept in a
   separate context and thus separated from the other data.

Top      Up      ToC       Page 72 
   In some situations, this data separation might not be sufficient.
   Circumstances where the VPN tunnel traverses other than only trusted
   and SP controlled network parts require stronger confidentiality
   measures such as cryptographic data encryption.  This is the case in
   certain inter-SP VPN scenarios or when the considered SP is on itself
   a client of a third party network provider.

   For layer 3 provider-provisioned CE-based VPNs, the SP network does
   not bare responsibility for confidentiality assurance, as the SP just
   offers IP connectivity.  The confidentiality will then be enforced at
   the CE and will lie in the tunneling (data separation) or in the
   cryptographic encryption (e.g., using IPsec) by the CE device.

   Note that for very sensitive user data (e.g., used in banking
   operations) the VPN customer may not outsource his data privacy
   enforcement to a trusted SP.  In those situations, PE-to-PE
   confidentiality will not be sufficient and end-to-end cryptographic
   encryption will be implemented by the VPN customer on its own private
   equipment (e.g., using CE-based VPN technologies or cryptographic
   encryption over the provided VPN connectivity).

6.6.  User Data and Control Data

   An important remark is the fact that both the user data and the VPN
   control data must be protected.

   Previous subsections were focused on the protection of the user data,
   but all the control data (e.g., used to set up the VPN tunnels, used
   to configure the VFI's or the CE devices (in the context of layer 3
   provider-provisioned CE-based VPNs)) will also be secured by the SP
   to prevent deliberate misconfiguration of provider-provisioned VPNs.

6.7.  Security Considerations for Inter-SP VPNs

   In certain scenarios, a single VPN will need to cross multiple SPs.

   The fact that the edge-to-edge part of the data path does not fall
   under the control of the same entity can have security implications,
   for example with regards to endpoint authentication.

   Another point is that the SPs involved must closely interact to avoid
   conflicting configuration information on VPN network elements (such
   as VFIs, PEs, CE devices) connected to the different SPs.

Top      Up      ToC       Page 73 
Appendix A: Optimizations for Tunnel Forwarding

A.1.  Header Lookups in the VFIs

   If layer 3 PE-based VPNs are implemented in the most straightforward
   manner, then it may be necessary for PE devices to perform multiple
   header lookups in order to forward a single data packet.  This
   section discusses an example of how multiple lookups might be needed
   with the most straightforward implementation.  Optimizations which
   might optionally be used to reduce the number of lookups are
   discussed in the following sections.

   As an example, in many cases a tunnel may be set up between VFIs
   within PEs for support of a given VPN.  When a packet arrives at the
   egress PE, the PE may need to do a lookup on the outer header to
   determine which VFI the packet belongs to.  The PE may then need to
   do a second lookup on the packet that was encapsulated across the VPN
   tunnel, using the forwarding table specific to that VPN, before
   forwarding the packet.

   For scaling reasons it may be desired in some cases to set up VPN
   tunnels, and then multiplex multiple VPN-specific tunnels within the
   VPN tunnels.

   This implies that in the most straightforward implementation three
   header lookups might be necessary in a single PE device: One lookup
   may identify that this is the end of the VPN tunnel (implying the
   need to strip off the associated header).  A second lookup may
   identify that this is the end of the VPN-specific tunnel.  This
   lookup will result in stripping off the second encapsulating header,
   and will identify the VFI context for the final lookup.  The last
   lookup will make use of the IP address space associated with the VPN,
   and will result in the packet being forwarded to the correct CE
   within the correct VPN.

A.2.  Penultimate Hop Popping for MPLS

   Penultimate hop popping is an optimization which is described in the
   MPLS architecture document [RFC3031].

   Consider the egress node of any MPLS LSP.  The node looks at the
   label, and discovers that it is the last node.  It then strips off
   the label header, and looks at the next header in the packet (which
   may be an IP header, or which may have another MPLS header in the
   case that hierarchical nesting of LSPs is used).  For the last node
   on the LSP, the outer MPLS header doesn't actually convey any useful
   information (except for one situation discussed below).

Top      Up      ToC       Page 74 
   For this reason, the MPLS standards allow the egress node to request
   that the penultimate node strip the MPLS header.  If requested, this
   implies that the penultimate node does not have a valid label for the
   LSP, and must strip the MPLS header.  In this case, the egress node
   receives the packet with the corresponding MPLS header already
   stripped, and can forward the packet properly without needing to
   strip the header for the LSP which ends at that egress node.

   There is one case in which the MPLS header conveys useful
   information: This is in the case of a VPN-specific LSP terminating at
   a PE device.  In this case, the value of the label tells the PE which
   LSP the packet is arriving on, which in turn is used to determine
   which VFI is used for the packet (i.e., which VPN-specific forwarding
   table needs to be used to forward the packet).

   However, consider the case where multiple VPN-specific LSPs are
   multiplexed inside one PE-to-PE LSP.  Also, let's suppose that in
   this case the egress PE has chosen all incoming labels (for all LSPs)
   to be unique in the context of that PE.  This implies that the label
   associated with the PE-to-PE LSP is not needed by the egress node.
   Rather, it can determine which VFI to use based on the VPN-specific
   LSP.  In this case, the egress PE can request that the penultimate
   LSR performs penultimate label popping for the PE-to-PE LSP.  This
   eliminates one header lookup in the egress LSR.

   Note that penultimate node label popping is only applicable for VPN
   standards which use multiple levels of LSPs.  Even in this case
   penultimate node label popping is only done when the egress node
   specifically requests it from the penultimate node.

A.3.  Demultiplexing to Eliminate the Tunnel Egress VFI Lookup

   Consider a VPN standard which makes use of MPLS as the tunneling
   mechanism.  Any standard for encapsulating VPN traffic inside LSPs
   needs to specify what degree of granularity is available in terms of
   the manner in which user data traffic is assigned to LSPs.  In other
   words, for any given LSP, the ingress or egress PE device needs to
   know which LSPs need to be set up, and the ingress PE needs to know
   which set of VPN packets are allowed to be mapped to any particular

   Suppose that a VPN standard allows some flexibility in terms of the
   mapping of packets to LSPs, and suppose that the standard allows the
   egress node to determine the granularity.  In this case the egress
   node would need to have some way to indicate the granularity to the
   ingress node, so that the ingress node will know which packets can be
   mapped to each LSP.

Top      Up      ToC       Page 75 
   In this case, the egress node might decide to have packets mapped to
   LSPs in a manner which simplifies the header lookup function at the
   egress node.  For example, the egress node could determine which set
   of packets it will forward to a particular neighbor CE device.  The
   egress node can then specify that the set of IP packets which are to
   use a particular LSP correspond to that specific set of packets.  For
   packets which arrive on the specified LSP, the egress node does not
   need to do a header lookup on the VPN's customer address space: It
   can just pop the MPLS header and forward the packet to the
   appropriate CE device.  If all LSPs are set up accordingly, then the
   egress node does not need to do any lookup for VPN traffic which
   arrives on LSPs from other PEs (in other words, the PE device will
   not need to do a second lookup in its role as an egress node).

   Note that PE devices will most likely also be an ingress routers for
   traffic going in the other direction.  The PE device will need to do
   an address lookup in the customer network's address space in its role
   as an ingress node.  However, in this direction the PE still needs to
   do only a single header lookup.

   When used with MPLS tunnels, this optional optimization reduces the
   need for header lookups, at the cost of possibly increasing the
   number of label values which need to be assigned (since one label
   would need to be assigned for each next-hop CE device, rather than
   just one label for every VFI).

   The same approach is also possible when other encapsulations are
   used, such as GRE [RFC2784] [RFC2890], IP-in-IP [RFC2003] [RFC2473],
   or IPsec [RFC2401] [RFC2402].  This requires that distinct values are
   used for the multiplexing field in the tunneling protocol.  See
   section 4.3.2 for detail.


   This document is output of the framework document design team of the
   PPVPN WG.  The members of the design team are listed in the
   "contributors" and "author's addresses" sections below.

   However, sources of this document are based on various inputs from
   colleagues of authors and contributors.  We would like to thank
   Junichi Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano,
   Naoto Makinae, Kenichi Kitami, Rajesh Balay, Anoop Ghanwani, Harpreet
   Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and Abbie

   We would also like to thank Yakov Rekhter, Scott Bradner, Dave
   McDysan, Marco Carugi, Pascal Menezes, Thomas Nadeau, and Alex Zinin
   for their valuable comments and suggestions.

Top      Up      ToC       Page 76 
Normative References

   [PPVPN-REQ]    Nagarajan, A., Ed., "Generic Requirements for Provider
                  Provisioned Virtual Private Networks (PPVPN)", RFC
                  3809, June 2004.

   [L3VPN-REQ]    Carugi, M., Ed. and D. McDysan, Ed., "Service
                  Requirements for Layer 3 Provider Provisioned Virtual
                  Private Networks (PPVPNs)", RFC 4031, April 2005.

Informative References

   [BGP-COM]      Sangli, S., et al., "BGP Extended Communities
                  Attribute", Work In Progress, February 2005.

   [MPLS-DIFF-TE] Le Faucheur, F., Ed., "Protocol extensions for support
                  of Differentiated-Service-aware MPLS Traffic
                  Engineering", Work In Progress, December 2004.

   [VPN-2547BIS]  Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.

   [VPN-BGP-OSPF] Rosen, E., et al., "OSPF as the Provider/Customer Edge
                  Protocol for BGP/MPLS IP VPNs", Work In Progress, May

   [VPN-CE]       De Clercq, J., et al., "An Architecture for Provider
                  Provisioned CE-based Virtual Private Networks using
                  IPsec", Work In Progress.

   [VPN-DISC]     Ould-Brahim, H., et al., "Using BGP as an Auto-
                  Discovery Mechanism for Layer-3 and Layer-2 VPNs,"
                  Work In Progress.

   [VPN-L2]       Andersson, L. and E. Rosen, Eds., "Framework for Layer
                  2 Virtual Private Networks (L2VPNs)", Work In

   [VPN-VR]       Knight, P., et al., "Network based IP VPN Architecture
                  Using Virtual Routers", Work In Progress, July 2002.

   [RFC1195]      Callon, R., "Use of OSI IS-IS for Routing in TCP/IP
                  and Dual Environments", RFC 1195, December 1990.

Top      Up      ToC       Page 77 
   [RFC1771]      Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
                  (BGP-4)", RFC 1771, March 1995.

   [RFC1918]      Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
                  G., and E. Lear, "Address Allocation for Private
                  Internets", BCP 5, RFC 1918, February 1996.

   [RFC1966]      Bates, T., "BGP Route Reflection: An alternative to
                  full mesh IBGP", RFC 1966, June 1996.

   [RFC1997]      Chandra, R., Traina, P., and T. Li, "BGP Communities
                  Attribute", RFC 1997, February 2001.

   [RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
                  October 1996.

   [RFC2205]      Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                  Jamin, "Resource ReSerVation Protocol (RSVP) --
                  Version 1 Functional Specification", RFC 2205,
                  September 1997.

   [RFC2208]      Mankin, A., Ed., Baker, F., Braden, B., Bradner, S.,
                  O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
                  "Resource ReSerVation Protocol (RSVP) Version 1
                  Applicability Statement Some Guidelines on
                  Deployment", RFC 2208, September 1997.

   [RFC2210]      Wroclawski, J., "The Use of RSVP with IETF Integrated
                  Services", RFC 2210, September 1997.

   [RFC2211]      Wroclawski, J., "Specification of the Controlled-Load
                  Network Element Service", RFC 2211, September 1997.

   [RFC2212]      Shenker, S., Partridge, C., and R. Guerin,
                  "Specification of Guaranteed Quality of Service", RFC
                  2212, September 1997.

   [RFC2207]      Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
                  Data Flows", RFC 2207, September 1997.

   [RFC2328]      Moy, J., "OSPF Version 2", STD 54, RFC 2328, April

   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [RFC2402]      Kent, S. and R. Atkinson, "IP Authentication Header",
                  RFC 2402, November 1998.

Top      Up      ToC       Page 78 
   [RFC2406]      Kent, S. and R. Atkinson, "IP Encapsulating Security
                  Payload (ESP)", RFC 2406, November 1998.

   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.

   [RFC2453]      Malkin, G., "RIP Version 2", STD 56, RFC 2453,
                  November 1994.

   [RFC2473]      Conta, A. and S. Deering, "Generic Packet Tunneling in
                  IPv6 Specification", RFC 2473, December 1998.

   [RFC2474]      Nichols, K., Blake, S., Baker, F., and D. Black,
                  "Definition of the Differentiated Services Field (DS
                  Field) in the IPv4 and IPv6 Headers", RFC 2474,
                  December 1998.

   [RFC2475]      Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                  Z., and W. Weiss, "An architecture for Differentiated
                  Services", RFC 2475, December 1998.

   [RFC2597]      Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
                  "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2661]      Townsley, W., Valencia, A., Rubens, A., Pall, G.,
                  Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
                  'L2TP'", RFC 2661, August 1999.

   [RFC2684]      Grossman, D. and J. Heinanen, "Multiprotocol
                  Encapsulation Over ATM Adaptation Layer 5", RFC 2684,
                  September 1999.

   [RFC2685]      Fox B. and B. Gleeson, "Virtual Private Networks
                  Identifier," RFC 2685, September 1999.

   [RFC2746]      Terzis, A., Krawczyk, J., Wroclawski, J., and L.
                  Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
                  January 2000.

   [RFC2764]      Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
                  A. Malis, "A Framework for IP Based Virtual Private
                  Networks", RFC 2764, February 2000.

   [RFC2784]      Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                  Traina, "Generic Routing Encapsulation (GRE)", RFC
                  2784, March 2000.

Top      Up      ToC       Page 79 
   [RFC2890]      Dommety, G., "Key and Sequence Number Extensions to
                  GRE", RFC 2890, September 2000.

   [RFC2858]      Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
                  "Multiprotocol Extensions for BGP-4", RFC 2858, June

   [RFC2983]      Black, D., "Differentiated Services and Tunnels", RFC
                  2983, October 2000.

   [RFC3031]      Rosen, E., Viswanathan, A., and R. Callon,
                  "Multiprotocol Label Switching Architecture", RFC
                  3031, January 2001.

   [RFC3032]      Rosen E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                  Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                  Encoding", RFC 3032, January 2001.

   [RFC3035]      Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
                  Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using
                  LDP and ATM VC Switching", RFC 3035, January 2001.

   [RFC3065]      Traina, P., McPherson, D., and J. Scudder, "Autonomous
                  System Confederations for BGP", RFC 3065, June 1996.

   [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                  LSP Tunnels", RFC 3209, December 2001.

   [RFC3246]      Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
                  Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V.,
                  and D. Stiliadis, "An Expedited Forwarding PHB (Per-
                  Hop Behavior)", RFC 3246, March 2002.

   [RFC3270]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                  Vaananen, P., Krishnan, R., Cheval, P., and J.
                  Heinanen, "Multi-Protocol Label Switching (MPLS)
                  Support of Differentiated Services", RFC 3270, May

   [RFC3377]      Hodges, J. and R. Morgan, "Lightweight Directory
                  Access Protocol (v3): Technical Specification", RFC
                  3377, September 2002.

Top      Up      ToC       Page 80 
Contributors' Addresses

   Jeremy De Clercq
   Fr. Wellesplein 1,
   2018 Antwerpen, Belgium


   Bryan Gleeson
   313 Fairchild Drive,
   Mountain View, CA 94043  USA.


   Andrew G. Malis
   90 Rio Robles Drive
   San Jose, CA 95134  USA


   Karthik Muthukrishnan
   Lucent Technologies
   1 Robbins Road
   Westford, MA 01886, USA


   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA, 01719, USA


   Chandru Sargor
   Redback Networks
   300 Holger Way
   San Jose, CA 95134, USA


Top      Up      ToC       Page 81 
   Jieyun Jessica Yu
   University of California, Irvine
   5201 California Ave., Suite 150,
   Irvine, CA, 92697  USA


Authors' Addresses

   Ross Callon
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886-3146, USA


   Muneyoshi Suzuki
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan


Top      Up      ToC       Page 82 
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-


   Funding for the RFC Editor function is currently provided by the