Internet Draft Internet Engineering Task Force M. Suzuki and J. Sumimoto, Editors INTERNET-DRAFT NTT Expires January 14, 2001 July 14, 2000 A Framework for Network-based VPNs <draft-suzuki-nbvpn-framework-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The objective of this draft is to clarify a framework for standardizing the mechanisms supporting interoperable network-based virtual private networks (NBVPNs). These are VPNs using IP facilities whose operation mechanisms are implemented within a network (or networks) and outsourced to one or more service providers. This draft first describes the assumed services of NBVPNs and clarifies the logical architecture model and reference model of NBVPN. Considering the assumed services, this draft further clarifies the NBVPN requirements for interfaces and MIBs in the reference model. It also surveys and discusses current technologies supporting NBVPNs such as tunneling, VPN identifier, routing, and QoS/SLA. Additionally it will, in future, provide outline of the interface and MIB specifications and present criteria for achieving interoperability. Suzuki & Sumimoto Ed. Expires January 2001 [Page 1] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 1. Objective and Scope of this Document The objective of this document is to clarify a framework for standardizing the mechanisms supporting interoperable network-based virtual private networks (NBVPNs). This framework includes assumed services of NBVPN for which interoperable solutions need to be developed, a logical architecture model and reference model of NBVPN, requirements for interfaces and MIBs of the NBVPN reference model, an outline of the interface and MIB specifications, overview of related technologies, and criteria for achieving interoperability. A VPN is defined as an emulation of a private wide area network; in particular, a VPN using IP is called an IP-VPN [RFC2764]. Since IP- VPNs have lower costs and more flexible service provisioning than VPNs based on other technologies, various IP-VPN implementations have been developed and some of them have been used in public services. IP-VPNs are further classified into "network-based VPNs (NBVPNs)" and "customer premises equipment (CPE)-based VPNs." The NBVPN is an IP- VPN whose VPN operations mechanisms are implemented within a network (or networks) and outsourced to one or more service providers (SPs) [RFC2764]. Compared with a CPE-based VPN, in which the VPN operations mechanisms are implemented in CPE, the NBVPN has the advantage of reducing the customer's overhead for VPN operations, so it is attracting the attention of Internet users and SPs. Looking at current implementations of NBVPNs, we see that a single technology cannot serve as the base technology, so various technologies such as MPLS [MPLS-ARC] [MPLS-FRAME] and IPsec [RFC2401] have been used. However, there has been no theoretical or practical way of achieving interworking among NBVPNs even though they have similar mechanisms. Thus, early provision of such a solution is eagerly awaited by Internet users and SPs. In order to support the standardization activity (responding to demands) to provide solutions for NBVPN interworking, this framework is created and serves as the basis for standardization in terms of architecture and specifications of NBVPNs. This standardization work aims to avoid applying excessive constraints to the mechanisms and specifications of base technologies (e.g., tunneling mechanisms) so that future advances in the base technologies for NBVPN can also be accommodated within this framework. This standardization work does not intend to modify any currently used mechanisms or specifications of the base technologies, either. The NBVPNs targeted by this framework are: o Virtual private routed networks, which are defined as an emulation of a multi-site wide area routed network using IP [RFC2764]. Suzuki & Sumimoto Ed. Expires January 2001 [Page 2] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 Excluded are: o NBVPNs using VPN native (non-IP) protocols as their base technologies. However, this does not mean to exclude multi- protocol access to the NBVPN by users. o Virtual leased lines, which provide a point-to-point link between two user sites [RFC2764]. o Virtual private dialup networks, which are defined as an emulation of on-demand isolated IP reachability from a remote user to a user site. The remote user is connected via a dial-up PSTN or ISDN link [RFC2764]. o Virtual private LAN segments, which are defined as an emulation of a LAN segment using Internet facilities [RFC2764]. This standardization is expected to lead to the following benefits. o Benefits to SPs It will enable flexible NBVPN implementation over multi-vendor multi-mechanism subnetworks. It will remove the constraint that all user sites of an NBVPN are limited to a specific vendor or mechanism. It will also lead to a lower costs than with the uniform NBVPN implementation. o Benefits to customers Customers will have more chance to construct wider area (e.g., international) NBVPNs as a result of the multi-SP multi-vendor environments provided by this technology. They will also get cheaper NBVPN services. In this document, section 2 describes assumed services of NBVPNs, section 3 clarifies the logical architecture model and reference model for NBVPNs, section 4 clarifies requirements for interfaces and MIBs in the NBVPN reference model, and section 5 outlines interface and MIB specifications. Moreover, section 6 surveys current mechanisms and discusses their issues, section 7 discusses criteria for achieving interoperability, and section 8 describes security considerations. Suzuki & Sumimoto Ed. Expires January 2001 [Page 3] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 2. Assumed Services of NBVPNs This section describes assumed services of NBVPNs in order to extract the requirements for mechanisms to be standardized for interoperable NBVPNs. They are provided to user sites by the networks. 2.1 Closed User Group (CUG) Various specific user sites forming a closed user group (CUG) can communicate with each other through an NBVPN. Other user sites cannot reach them. This is the basic service of an NBVPN. Operation mechanisms are implemented within a network and the operations are performed by an SP. This service prevents packets from being injected into the network without authorization. It also prevents packets from being snooped on, modified in transit, or subjected to traffic analysis by unauthorized parties. Private IP addressing may be used in a CUG. 2.2 Extranets Multiple NBVPNs are interconnected within the networks. Access control (including packet filtering and address translation) may be applied between NBVPNs according to policy. Interconnection of NBVPNs performed in user sites is outside the scope of this document. 2.3 QoS/SLA NBVPN-specific SLAs covering loss rates, jitter, latency, and bandwidth etc. are guaranteed and/or differentiated. Various classes of QoS are provided, although they may depend on the supporting technologies, e.g., IntServ [RFC2211] [RFC2212], DiffServ [RFC2474] [RFC2475], or L2 traffic engineering capabilities. 2.4 Dynamic Routing Unicast routing information is exchanged between user sites and NBVPN using routing protocol such as Open Shortest Path First (OSPF) [RFC2328] or Border Gateway Protocol 4 (BGP-4) [RFC1771]. Routing information about each user site can be exchanged between user sites. This service is essential for multihomed user sites, while the major purpose of multihoming is to improve reliability. 2.5 Multiprotocol Transport Traffic is carried between user sites using various different protocols. Suzuki & Sumimoto Ed. Expires January 2001 [Page 4] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 2.6 Data Security Stronger security than that of the basic service is provided by encryption and authentication. 2.7 NBVPN over multiple SPs A single NBVPN is provided over multiple SPs. 2.8 Multicast Multicast packets forwarded from user sites are replicated in the networks and forwarded to multiple user sites. Multicast routing information is exchanged between user sites and NBVPN using multicast routing protocol. 3. Logical Architecture Model and Reference Model for NBVPN This section describes the logical architecture model and reference model for NBVPN. These will be used in mapping the NBVPN service descriptions in section 2 to NBVPN requirements described in section 4. 3.1 Logical Architecture Model for NBVPN The logical architecture model for NBVPN describes functions and their relationship for implementing NBVPN. Figure 3.1 shows the logical architecture model. +-------------------------------+ | MIBs and Management Framework | +-------------------------------+ | +-------+ Access VR VR Access +-------+ |CPE of | link +----+ tunnel +----+ tunnel +----+ link | CPE of| |NBVPN A+--------| VR |=========| VR |=========| VR |--------|NBVPN A| +-------+ +----+ +----+ +----+ +-------+ VR: Virtual Router Figure 3.1: Logical architecture model. Suzuki & Sumimoto Ed. Expires January 2001 [Page 5] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 +----+ VR tunnel +----+ +-----+ | |=============================| VR |-------+ CPE | +-----+ | | +----+ +-----+ | CPE +-------| VR | +-----+ | | VR tunnel +----+ +-----+ | |=============================| VR |-------+ CPE | +----+ +----+ +-----+ +-----+ +----+ +----+ +----+ +----+ +-----+ | CPE +-------| | | | | |======| VR |-------+ CPE | +-----+ | |======| | | | +----+ +-----+ +-----+ | VR | | | | | | CPE +-------| | | VR |=====| VR | +-----+ +----+ | | | | +-----+ +----+ | | | | +----+ +-----+ | CPE +-------| VR |======| | | |======| VR |-------+ CPE | +-----+ +----+ +----+ +----+ +----+ +-----+ Figure 3.2: Example configurations applying the logical architecture model. Figure 3.1 shows a generalized model. It can represent various NBVPN configurations, as shown in Figure 3.2. The entities in the logical architecture model are described below. o Virtual router (VR) A VR supports router functions dedicated to a serving NBVPN. It has the following functions. - Routing function: A VR creates, modifies, and maintains a routing table of the serving NBVPN using routing protocols. - Forwarding function: A VR forwards IP packets within the NBVPN by looking up entries in the routing table. - Access control function: A VR may control access (packet filtering and address translation) from other NBVPNs or from the Internet. o VR tunnel A VR tunnel is a connection (isolated from other NBVPNs and the Internet) between VRs whose serving NBVPNs are identical. A VR tunnel is terminated by VRs. Note that intermediate devices between VRs may also support the tunnel mechanism for packet forwarding, but this topic is outside the scope of the logical Suzuki & Sumimoto Ed. Expires January 2001 [Page 6] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 architecture model. o CPE CPE provides the functionality of a NBVPN user site. o Access link An access link provides CPE with access to services associated with a specific NBVPN. Note that a physical facility may multiplex multiple access lines, but this is outside the scope of this model. o MIBs and management framework These represent MIBs for managing the customer configuration associated with the concerned VPN, MIBs for managing VRs, and other devices constructing the concerned NBVPN and associated managing functions. Suzuki & Sumimoto Ed. Expires January 2001 [Page 7] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 3.2 Reference Model In order to clarify possible mapping between the logical architecture model given in section 3.1 and implementation as well as to clarify the targets of the standardization work, this section describes a reference model illustrating the reference configuration of the NBVPN. Figure 3.3 shows the reference model. : +----------------------------------------+ : +-----+ : | | : +-----+ |User | : | +------+ +------+ : | User| |site | : | ED | Edge | ED | Edge | : | site| | of | : +------+ tunnel : |device| : tunnel |device| : | of | |NBVPN+-:--| |========:====| |====:========| |--:-+NBVPN| | A | : | | : +------+ : +------+ : | A | +-----+ : | Edge | : : | : +-----+ +-----+ : |device| Network-facing-side interface | : +-----+ |User | : | | : +------+ : | User| |site +-:--| |=================:================| Edge |--:-+ site| | of | : +------+ : |device| : | of | |NBVPN| : | | | | | : |NBVPN| | B | : | +------+------+ +-----+-----+ +------+ : | B | +-----+ : | |NMS for | |NMS for | | : +-----+ : | |customer MIBs| |device MIBs| | : : | +-------------+ +-----------+ | : : | | : : +----------------------------------------+ : : |<------------- Network(s) ------------->| : : | single or multiple SP domains | : : : Customer-facing- Customer-facing- side interface side interface Figure 3.3: Reference model. o User site A user site represents an implementation of CPE in the logical architecture model. A user site belongs to only one NBVPN, although it can reach other NBVPNs through an extranet service. A user site is usually accommodated by a single edge device. However, four types of double-homing arrangements, shown in Figure 3.4, are also supported. Suzuki & Sumimoto Ed. Expires January 2001 [Page 8] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 +---------------- +--------------- | | +------+ +------+ +---------| Edge | +---------| Edge | | |device| | |device| Network | +------+ | +------+ +-----+ | +-----+ | |User | | |User | +--------------- |site | | Network |site | +--------------- +-----+ | +-----+ | | +------+ | +------+ | | Edge | | | Edge | +---------|device| +---------|device| Network +------+ +------+ | | +---------------- +--------------- This type includes a user site connected to an edge device via two access lines. (a) (b) +---------------- +--------------- | | +-----+ +------+ +-----+ +------+ |User |------| Edge | |User |------| Edge | |site | |device| |site | |device| Network +-----+ +------+ +-----+ +------+ | | | | | Backdoor | | Backdoor +--------------- | link | Network | link +--------------- | | | | +-----+ +------+ +-----+ +------+ |User | | Edge | |User | | Edge | |site |------|device| |site |------|device| Network +-----+ +------+ +-----+ +------+ | | +---------------- +--------------- (c) (d) Figure 3.4: Four types of double-homing arrangements. o Networks NBVPN services are provided by one or more networks to user sites as members of the concerned NBVPN. These networks support edge devices, ED tunnels, NMSs for customer and device MIBs. In this document, "a network" means a singe domain of an SP. The NBVPN Suzuki & Sumimoto Ed. Expires January 2001 [Page 9] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 operation in a network is outsourced to an SP, but the whole NBVPN operation may be spread over multiple SPs. o Edge device An edge device implements one or more VRs. It is usually located at the edge of a network. It may terminate access links. o ED tunnel An ED tunnel is a connection between EDs. Multiple VR tunnels defined in section 3.1 may be multiplexed into a single ED tunnel. A number of IP tunneling protocols have been proposed, but in this document, three different ED tunneling mechanisms--that is MPLS, GRE, and IPsec--are considered to support NBVPN. A single NBVPN may make use of a mixture of tunneling mechanisms. When MPLS is used for the ED tunneling mechanism, it is implemented by a LSP and two multiplexing schemes are supported. The first scheme uses two-layer label stacking of the MPLS. In this scheme, the multiple VR tunnels identified by second labels are multiplexed in the ED tunnel identified by the top label. The second scheme is applicable when the MPLS network is implemented by ATM, and it uses the CPCS user-to-user field in the AAL5 trailer or the VPN-ID field in the VPN encapusulation header [RFC2684]. In this scheme, the multiple VR tunnels in the ED tunnel are identified by the CPCS-UU or VPN-ID field respectively. When GRE is used for the ED tunneling mechanism and the key field option is supported, the VR tunnels are identified by the key field. Note that if the key field is not present, the ED tunnel supports only one VR tunnel. When IPsec is used, they are identified by the SPI field. Note that when the ED tunnel is provided by GRE or IPsec, it may pass through another tunneling mechanism (e.g., an IPsec tunnel over an MPLS network). In this document, an ED tunnel is identical to the tunnel that directly multiplexes VR tunnels and does not include underlying tunneling mechanisms. Figure 3.5 illustrates VR tunnel multiplexing. Multiple VR tunnels supporting connections for NBVPNs are multiplexed into an ED tunnel. This arrangement allows multiplexing of VR tunnels of different NBVPNs. Suzuki & Sumimoto Ed. Expires January 2001 [Page 10] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 +-------------+ +-------------+ | | ED tunnel | | | | +----------------------------+ | | | +-------+ | : : | +-------+ | | | VR of |========================================| VR of | | | |NBVPN A| | : VR tunnel : | |NBVPN A| | | +-------+ | : : | +-------+ | | +-------+ | : : | +-------+ | | | VR of |========================================| VR of | | | |NBVPN B| | : VR tunnel : | |NBVPN B| | | +-------+ | : : | +-------+ | | +-------+ | : : | +-------+ | | | VR of |========================================| VR of | | | |NBVPN C| | : VR tunnel : | |NBVPN C| | | +-------+ | : : | +-------+ | | | +----------------------------+ | | +-------------+ +-------------+ Edge device Edge device Figure 3.5: VR tunnel multiplexing. o NMS for customer MIB An NMS that manages customer MIBs of an NBVPN. o NMS for device MIB An NMS that manages device MIBs of an NBVPN. The targets of the standardization work are the following two interfaces and MIBs illustrated in the reference model given in Figure 3.3. o Customer-facing-side interface An interface between a user site and an edge device. o Network-facing-side interface An interface between edge devices. o Customer MIBs MIBs of NBVPN customer attributes. Suzuki & Sumimoto Ed. Expires January 2001 [Page 11] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Device MIBs MIBs of device attributes, covering VRs and other devices constructing the concerned NBVPN. 3.3 Identifiers (IDs) Various IDs play a key role in specifying the interfaces and MIBs introduced in section 3.2. Some of them are mutually dependent, i.e., an ID type is unique within the scope of another ID type. For example, the ID of each edge device is defined as unique within the scope of the ID of the SP operating those edge devices. The IDs that have been identified so far are: service provider ID (SP-ID), VPN-ID, user site ID (US-ID), device ID (DEV-ID), logical port ID (LPORT-ID), ED tunnel ID (EDTUNNEL-ID), and VR tunnel ID (VRTUNNEL-ID). A detailed VPN information model describing the relationship among these IDs is given in section 4 of this framework. 4. Requirements for Interfaces and MIBs 4.1 General Requirements The implementation providing an NBVPN must: o be scalable o be manageable o enable a single NBVPN to span multiple subnetworks implemented with different technologies. For example, a single NBVPN must be able to span IPsec- and MPLS-based-subnetworks. o enable a single NBVPN to span multiple SPs. 4.2 Classification of Network-facing-side Interface In this section, the network-facing-side interface shown in Figure 3.3 is classified into three specific interfaces. It is not necessary for a single SP's whole network to be constructed with a uniform technology. As shown in Figure 4.1, different subnetworks may be implemented with different technologies. In this case, an edge device must be placed at the edge of a subnetwork interconnecting with another subnetwork that is based on another technology. In this document, it is called a subnetwork edge device (SED). Suzuki & Sumimoto Ed. Expires January 2001 [Page 12] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 +---------------------------------------------------------------+ | +-------------------+ +-------------------+ | | | ED | ED | ED +----+ +----+tunnel : +---+tunnel : +---+tunnel : |Edge| | |=======:=======| |=======:=======| |=======:=======|de- | | | : | | : | | : |vice| | | Intra- | | Subnetwork | | : +----+ |Edge| subnetwork | | interworking | |Intra-subnetwork | | |de- | interface |SED| interface |SED| interface | | |vice| : | | : | | : +----+ | |ED : | |ED : | |ED : |Edge| | |tunnel : | |tunnel : | |tunnel : |de- | | |=======:=======| |=======:=======| |=======:=======|vice| +----+ : +---+ : +---+ : +----+ | | : | : | : | | | +-------------------+ +-------------------+ | | |<- Subnetwork(s) ->| |<- Subnetwork(s) ->| | | implemented with implemented with | | a uniform technology a uniform technology | | | +---------------------------------------------------------------+ |<-------------------------- Network -------------------------->| Figure 4.1: Intra-subnetwork interface and subnetwork interworking interface. +---------------------------------------------------------------+ | +-------------------+ +-------------------+ | | | | ED | +----+ +----+ ED tunnel +---+tunnel : +---+ ED tunnel |Edge| | |===============| |=======:=======| |===============|de- | | | | | : | | |vice| | | | | : | | +----+ |Edge| | |SP interworking| | | | |de- | |PED| interface |PED| | | |vice| | | : | | +----+ | | | |ED : | | |Edge| | | ED tunnel | |tunnel : | | ED tunnel |de- | | |===============| |=======:=======| |===============|vice| +----+ +---+ : +---+ +----+ | | | : | | | | +-------------------+ +-------------------+ | | |<---- Network ---->| |<---- Network ---->| | | | +---------------------------------------------------------------+ |<------------------------- Networks -------------------------->| Figure 4.2: SP interworking interface. Suzuki & Sumimoto Ed. Expires January 2001 [Page 13] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 Similarly, when a single NBVPN spans multiple SPs, edge devices should be placed at every SP interconnecting point as shown in Figure 4.2. In this document, they are called provider edge devices (PEDs). In the rest of this document, SEDs and PEDs are also simply called "edge devices" unless they need to be differentiated. The intra-subnetwork interface and subnetwork interworking interface are defined as shown in Figure 4.1. The former interface exists between a pair of edge devices and is restricted to one or more subnetworks implemented with a uniform technology. The latter interface exists between a pair of SEDs and connects two subnetworks implemented with different technologies. The SP interworking interface is defined as shown in Figure 4.2. It exists between a pair of PEDs and connects two SP networks. Suzuki & Sumimoto Ed. Expires January 2001 [Page 14] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 4.3 Requirements for Identifiers This section clarifies the requirements for the identifiers to describe the requirements for the interfaces and MIBs. Several identifiers are defined, as illustrated in Figure 4.3. EDTUNNEL EDTUNNEL -ID -ID DEV VR | | VR DEV -ID TUNNEL | | TUNNEL -ID LPORT | -ID | | -ID | US-ID -ID | | | | | | | | V | V ED tunnel V | V | | +----+ | +-+---------------------------+-+ | +----+ V | | | V : VR tunnel : V | | +----+ | | |=+===================================+=| | | | V | | : VR Tunnel : |SED | |User| | | |=+===================================+=| | |site+-+--| | : : | | | | | | | +-+---------------------------+-+ | | +----+ | | +----+ |Edge| ED tunnel +----+ | |de- | +-+---------------------------+-+ +----+ | +-+--|vice| : VR tunnel : | | | | | | |=+===================================+=| | +----+ |User| | | : VR tunnel : | | | | |Site| | |=+===================================+=| | | |User| | | | | | : VR tunnel : | |--+-+site| | +-+--| |=+===================================+=| | | | | +----+ | | | : : |Edge| +----+ | | +-+---------------------------+-+ |de- | +----+ |vice| +----+ ED tunnel | | | | +----+ +-+---------------------------+-+ | | | |User| | | : VR tunnel : | |--+-+site| | |=+===================================+=| | | | | |PED | : VR tunnel : | | +----+ | |=+===================================+=| | | | : : | | +----+ +-+---------------------------+-+ +----+ Figure 4.3: Identifiers. o SP-ID, which identifies each SP, must be unique at least within all the interconnected networks of SPs. (In practice, it should be globally unique.) This is necessary when a single NBVPN spans multiple SPs. Suzuki & Sumimoto Ed. Expires January 2001 [Page 15] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o VPN-ID, which identifies each NBVPN, must be unique at least within each SP's network. o US-ID, which identifies each user site, must be unique at least within each SP's network. o DEV-ID, which identifies each edge device, must be unique at least within each SP's network. The DEV-ID of a PED must be unique at least within all the interconnected SP networks. Note: One of the IP addresses assigned to an edge device is usually used as DEV-ID. o LPORT-ID, which identifies a logical port, must be unique at least within each edge device containing the logical port. Here, a logical port represents a terminating point of an access link accommodating a user site. o EDTUNNEL-ID, which identifies each ED tunnel, must be unique at least within each edge device supporting the ED tunnel. o VRTUNNEL-ID, which identifies each VR tunnel, must be unique at least within each ED tunnel supporting the VR tunnel. The scope of the identifiers is summarized in Figure 4.4. It shows that the right-side identifier must be unique at least within the scope of the left-side identifier for each arrow. SP-ID +--> VPN-ID | +--> US-ID | +--> DEV-ID +--> LPORT-ID | +--> EDTUNNEL-ID ---> VRTUNNEL-ID Figure 4.4: Scope of identifiers. When a single NBVPN spans multiple SPs, their identifiers, except for SP-ID, must satisfy one of the following conditions: 1) their mappings are predefined, 2) their mappings are dynamically built by a protocol, or 3) they are linked together with the SP-ID. The association among the identifiers must satisfy the following requirements. Suzuki & Sumimoto Ed. Expires January 2001 [Page 16] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o The US-ID must be mapped to one or more pairs of DEV-ID and LPORT- ID to configure the accommodation of user sites. Note that it is not necessary for the mapping to be built in a one-to-one manner because a user site may be connected to edge devices through multiple access links as shown in Figures 3.4(a) and (b). In this case, the US-ID must be mapped to all the concerned pairs of DEV-ID and LPORT-ID. o The US-ID must be uniquely mapped to the VPN-ID to distinguish the NBVPN associated with the user site. o A pair of DEV-ID and LPORT-ID must be uniquely mapped to the VPN-ID to distinguish the NBVPN associated with the logical port. o A set of DEV-ID, EDTUNNEL-ID, and VRTUNNEL-ID must be uniquely mapped to the VPN-ID to support a VR tunnel. 4.4 Requirements for the Interfaces 4.4.1 Customer-facing-side Interface This section describes the requirements for the customer-facing-side interface shown in Figure 3.3. o Packet Format Every packet must have the usual IP packet format without VPN-aware encapsulation, except in the case of providing multiprotocol transport service where every packet must have a protocol-specific packet format without VPN-aware encapsulation. o QoS/SLA For QoS/SLA service, every access link connecting a user site and an edge device must support the specified QoS/SLA. o Dynamic Routing Route control must be supported independently per access link connecting a user site and an edge device. For dynamic routing service, different routing protocols must be supported per access link. 4.4.2 Network-facing-side Interface This section describes the requirements for the three specific network-facing-side interfaces shown in Figures 4.1 and 4.2. Suzuki & Sumimoto Ed. Expires January 2001 [Page 17] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Packet Format Every packet must be encapsulated with the VRTUNNEL-ID. Multiprotocol transport service requires multiprotocol-over-IP encapsulation and data security service requires data encryption. o QoS/SLA For QoS/SLA service, every ED tunnel must support specified QoS/SLA per NBVPN. o Learning Other Edge Device Identifiers To set up tunnels between edge devices, every edge device must learn the DEV-ID of other edge devices. Therefore, every edge device must support static configuration for tunneling and may support a learning protocol. o Tunnel Setup To set up tunnels between VRs associated with the same NBVPN, every edge device must support static configuration for tunneling and may support a tunnel setup protocol. When edge devices support the protocol, the information exchanged between them includes the VPN- ID, EDTUNNEL-ID, VRTUNNEL-ID, QoS/SLA information for QoS/SLA service, data encryption and authentication information for data security service, and multiprotocol-over-IP encapsulation information for multiprotocol transport service. For multicast service, multicast traffic must be forwarded through the created tunnels. For data security service, the created tunnel must support data encryption and authentication. o Tunnel Management A protocol for monitoring tunnel states must be supported. A protocol for tunnel restoration must be supported. o Authentication and Encryption For data security service, a protocol for authentication and encryption must be supported. Suzuki & Sumimoto Ed. Expires January 2001 [Page 18] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Dynamic Routing Route control must be supported independently per NBVPN. Routing protocols on the SP interworking interface may support authentication. If policy routing is performed, routing protocols running between PEDs on the SP interworking interface may specify intermediate SPs by SP-ID in route distribution and then routing protocols running between PEDs on the intra-subnetwork and subnetwork interworking interface may also specify intermediate SPs by SP-ID in route distribution. 4.5 Requirements for MIBs 4.5.1 Customer MIB This section describes the requirements for the customer MIB shown in Figure 3.3. o Management information about user sites and customer attributes of NBVPN must be configured and maintained. The information includes the US-ID, DEV-ID, LPORT-ID, VPN-ID, access control policy information for extranet service, routing protocols used for dynamic routing or multicast service, and QoS/SLA information for QoS/SLA service. 4.5.2 Device MIB This section describes the requirements for the device MIB shown in Figure 3.3. o The configuration and maintenance of multiple VRs must be supported. Their management information includes IP routing information and access control policy information for extranet service. For multiprotocol transport service, protocol-specific routing information must be managed instead of IP routing information. o The mappings between the LPORT-ID and VPN-ID must be configured and maintained. For QoS/SLA service, the mappings between LPORT-ID and QoS/SLA information must also be configured and maintained. o Tunnel information must be configured and maintained. It includes the EDTUNNEL-ID, VRTUNNEL-ID, tunnel states, QoS/SLA information for QoS/SLA service, and encryption and authentication information for data security service. Suzuki & Sumimoto Ed. Expires January 2001 [Page 19] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Routing protocols running between VRs and user sites must be configured and maintained per VR. For multicast service, multicast routing protocols must also be supported. o Routing protocols running between VRs must be configured and maintained per VR. For multicast service, multicast routing protocols must also be supported. 5. Outline of Interface and MIB Specifications (To be written) 6. Survey of Available Technologies 6.1 Tunneling Tunneling mechanisms provide isolated and secure communication between two user sites. Available tunneling mechanisms include (but are not limited to): MPLS [MPLS-ARCH] [MPLS-FRAME] [MPLS-ATM], GRE [RFC2784] [GRE-EXT], and IPsec [RFC2401] [RFC2402]. In an NBVPN, a tunnel is a secure communication path within a network. An edge device encapsulates a data packet incoming from a user site, and injects it into an appropriate tunnel. The data packet traverses the network, and reaches the edge device on the far side. In the course of traversal, the data packet may have transferred to other tunnels, if necessary. The edge device then retrieves the data packet from a tunnel, and passes it to the destination user site. An informational RFC, "A Framework for IP Based Virtual Private Networks" [RFC2764], identifies ten desirable capabilities for tunneling technologies: o Multiplexing o Signaling protocol o Data security o Multiprotocol transport o Frame sequencing o Tunnel maintenance o Large MTUs o Minimization of tunnel overhead Suzuki & Sumimoto Ed. Expires January 2001 [Page 20] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Flow and congestion control o QoS/traffic management 6.1.1 MPLS [MPLS_ARCH] [MPLS_FRAME] [MPLS-ATM] Multiprotocol Label Switching (MPLS) is a method for forwarding packets through a network. Routers at the edge of a network apply simple labels to packets. A label may be inserted between the data link and network headers, or may be carried in the data link header (e.g., the VPI/VCI field in an ATM header). Routers in the network switch packets according to the labels with minimal lookup overhead. A path, or a tunnel in the NBVPN, is called a "label switched path (LSP)." o Multiplexing LSPs may be multiplexed into another LSP. o Signaling Protocol, and Tunnel Maintenance LSPs are set up and maintained by LDP (Label Distribution Protocol) [VPN-CRLDP] or RSVP (Resource Reservation Protocol) [LSP-RSVP]. o Data Security MPLS has no intrinsic security mechanisms. Some other mechanisms such as IPsec may be used with it. o Multiprotocol Transport MPLS can carry data packets other than IP ones. o Frame Sequencing MPLS guarantees in-order delivery of packets. o Large MTUs MPLS does not restrict the MTU size. o Minimization of Tunnel Overhead The overhead of label switching should be minimal. Suzuki & Sumimoto Ed. Expires January 2001 [Page 21] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Flow & Congestion Control and QoS/Traffic Management MPLS does not have intrinsic flow control or QoS management mechanisms. Some other techniques such as DiffServ may be used with it [DIFF-MPLS]. 6.1.2 GRE [RFC2784] [GRE-EXT] Generic Routing Encapsulation (GRE) specifies a protocol for encapsulating an arbitrary payload protocol over an arbitrary delivery protocol [RFC2784]. In particular, it may encapsulate an IP payload packet over IP. An endpoint encapsulates and decapsulates GRE packets. A GRE tunnel is a communication path between two endpoints established by the use of GRE. o Multiplexing The current GRE specification [RFC2784] does not support multiplexing. The key field, which is being proposed in [GRE-EXT], may be used as a multiplexing field. o Signaling Protocol and Tunnel Maintenance GRE is not equipped with standard ways for setting up and maintaining GRE tunnels. o Data Security GRE has no intrinsic security mechanisms. Some other mechanisms such as IPsec may be used with it. o Multiprotocol Transport GRE is assumed to support any type of payload protocols. o Frame Sequencing, Large MTUs, Flow & Congestion Control, and QoS/Traffic Management Those capabilities depend on the delivery protocol. The sequence field as proposed in [GRE-EXT] may be used to achieve in-order delivery. o Minimization of Tunnel Overhead The overhead of GRE depends on the choice of delivery protocols, but the GRE header overhead is designed to be minimal. Suzuki & Sumimoto Ed. Expires January 2001 [Page 22] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 6.1.3 IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2409] IP Security (IPsec) provides security services at the IP layer [RFC2401]. It comprises authentication header (AH) protocol [RFC2402], encapsulating security payload (ESP) protocol [RFC2406], and Internet key exchange (IKE) protocol [RFC2409]. AH protocol provides data integrity, data origin authentication, and an anti- replay service. ESP protocol provides data confidentiality and limited traffic flow confidentiality. It may also provide data integrity, data origin authentication, and an anti-replay service. AH and ESP may be used in combination. IPsec may be employed in either transport or tunnel mode. In transport mode, AH or ESP or both headers are inserted between the IPv4 header and the transport protocol header. In tunnel mode, an IP packet is encapsulated with an outer IP packet header. AH or ESP or both headers are inserted between them. AH and ESP establish a unidirectional secure communication path between two endpoints, which is called a security association. In tunnel mode, two security associations compose a tunnel. IKE protocol is used to exchange encryption keys among IPsec endpoints. o Multiplexing The SPI field of AH and ESP is used to multiplex security associations (or tunnels) within a tunnel. o Signaling Protocol, and Tunnel Maintenance IKE is used for the setup and maintenance of tunnels. o Data Security IPsec is designed to provide security services at the IP layer. o Multiprotocol Transport IPsec needs extensions to carry packets other than IP. Alternatively, GRE may be used with it. o Frame Sequencing IPsec has a sequence number field which is used by a receiver to perform an anti-replay check, not to guarantee in-order delivery of packets. Suzuki & Sumimoto Ed. Expires January 2001 [Page 23] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 o Large MTUs IPsec does not restrict the MTU size. o Minimization of Tunnel Overhead IPsec may impose its own overhead. o QoS/Traffic Management IPsec itself does not have intrinsic QoS/Traffic Management capabilities. Other mechanisms such as "RSVP Extensions for IPSEC Data Flows" [RFC2207] or DiffServ may be used with it. Note: IPsec is applicable to a CPE-based VPN as well as an NBVPN. This document deals with the aspects of IPsec that are relevant to an NBVPN. 6.2 VPN Identifiers An NBVPN spanning multiple autonomous systems requires the use of a globally unique VPN identifier such as "a pair of autonomous system- number and VPN-index local to autonomous system" and the "global VPN identifier" as specified in [RFC2685]. A globally unique VPN identifier may be included in an MIB for the VPN configuration. It may also be included in an encapsulation header of a data packet or may be exchanged as a parameter of signaling messages. The global VPN identifier defined in [RFC2685] consists of a 3-byte VPN organizationally unique identifier that identifies a VPN administrative authority, and a 4-byte VPN index that identifies the VPN within the context of a given VPN administrator. The VPN encapsulation header defined in [RFC2684] supports the global VPN identifier. But, it must be noted that the global VPN identifier, which is 56-bit long, does not fit into the 20-bit MPLS label or into the 32-bit IPsec SPI field. 6.3 Routing Dynamic routing service as defined in section 2 requires the exchange of routing information between a network and user sites. A list of applicable technologies is given in section 6.3.1. The network may terminate a routing protocol, or it may transfer routing information between user sites transparently. Suzuki & Sumimoto Ed. Expires January 2001 [Page 24] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 The network must maintain its routing configuration with integrity. The applicable technologies are listed in section 6.3.2. 6.3.1 Exchange of routing information between network and user sites The following technologies are available for the exchange of routing information between a network and user sites. o Static routing Routing tables may be configured through a management system. o RIP (Routing Information Protocol) [RFC2453] RIP is an interior gateway protocol and is used within an autonomous system. It sends out routing updates at regular intervals and whenever the network topology changes. Routing information is then propagated by the adjacent routers to their neighbors and thus to the entire network. A route from a source to a destination is the path with the least number of routers. This number is called the "hop count" and its maximum value is 15. This implies that RIP is suitable for a small- or medium-sized networks. o OSPF (Open Shortest Path First) [RFC1583] OSPF is an interior gateway protocol and is applied to a single autonomous system. Each router distributes the state of its interfaces and neighboring routers as a link-state advertisement, and maintains a database describing the autonomous system's topology. A link-state is advertised every 30 minutes or when the topology is reconfigured. Each router maintains an identical topological database, from which it constructs a tree of shortest-paths with itself as the root. The algorithm is known as the Shortest Path First or SPF. The router generates a routing table from the tree of shortest-paths. OSPF supports a variable length subnet mask, which enables effective use of the IP address space. OSPF allows sets of networks to be grouped together into an area. Each area has its own topological database. The topology of the area is invisible from outside of its area. The areas are interconnected via a "backbone" network. The backbone network distributes routing information between the areas. The area routing scheme can reduce the routing traffic and compute the shortest-path trees and is indispensable for larger-scale networks. Suzuki & Sumimoto Ed. Expires January 2001 [Page 25] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 Each multi-access network with multiple routers attached has a designated router. The designated router generates a link state advertisement for the multi-access network and synchronizes the topological database with other adjacent routers in the area. The concept of designated router can thus reduce the routing traffic and compute shortest-path trees. To achieve high availability, a backup designated router is used. o IS-IS (intermediate system to intermediate system) [RFC1195] IS-IS is a routing protocol designed for the OSI (Open Systems Interconnection) protocol suites. Integrated IS-IS is derived from IS-IS in order to support the IP protocol. In the Internet community, IS-IS means integrated IS-IS. In this, a link-state is advertised over a connectionless network service. IS-IS has the same basic features as OSPF. They include: link-state advertisement and maintenance of a topological database within an area, calculation of a tree of shortest-paths, generation of a routing table from a tree of shortest-paths, the area routing scheme, a designated router, and a variable length subnet mask. o BGP4 (Border Gateway Protocol version 4) [RFC1771] BGP4 is an exterior gateway protocol and is applied to the routing of inter-autonomous systems. A BGP speaker establishes a session with other BGP speakers and advertises routing information to them. A session may be an External BGP (EBGP) that connects two BGP speakers within different autonomous systems, or an internal BGP (IBGP) that connects two BGP speakers within a single autonomous system. Routing information is qualified with path attributes, which differentiate routes for the purpose of selecting an appropriate one from possible routes. Also, routes are grouped by the community attribute [RFC1997] [BGP-COM]. The IBGP mesh size tends to increase dramatically with the number of BGP speakers in an autonomous system. BGP can reduce the number of IBGP sessions by dividing the autonomous system into smaller autonomous systems and grouping them into a single confederation [RFC1965]. Route reflection is another way to reduce the number of IBGP sessions [RFC1966]. BGP divides the autonomous system into clusters. Each cluster establishes the IBGP full-mesh within itself, and designates one or more BGP speakers as "route reflectors," which communicate with other clusters via their route reflectors. Route reflectors in each cluster maintain path and attribute information across the autonomous system. The autonomous system still functions like a fully meshed autonomous system. On the other hand, confederations provide finer control of routing within the autonomous system by allowing for policy changes across Suzuki & Sumimoto Ed. Expires January 2001 [Page 26] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 confederation boundaries, while route reflection requires the use of identical policies. 6.3.2 Exchange of routing information within a network The following technologies can be used for exchanging routing information within a network. o Static routing o RIP o OSPF o BGP o Multiprotocol BGP4 [RFC2858] BGP4 has been extended to support IPv6, IPX, and others as well as IPv4 [RFC2283]. Multiprotocol BGP4 carries routes from multiple "address families." o Extended BGP4 [VPN-2547BIS] Extended BGP4 is a specific extension to Multiprotocol BGP4. The notion of "VPN-IPv4 address family" is introduced in [VPN-2547BIS]. A VPN-IPv4 address is 12 bytes long and consists of an 8-byte route distinguisher (RD) and a 4-byte IPv4 address. Overlapping of the IPv4 address space among multiple NBVPNs is resolved by using different RDs. Scalable configurations can be achieved by the use of route reflectors. 6.4 QoS/SLA The following technologies for QoS/SLA are applicable to an NBVPN. 6.4.1 ATM Asynchronous transfer mode (ATM) provides several service categories, such as CBR (constant bit rate) service, VBR (variable bit rate) service, and GFR (guaranteed frame rate) service. CBR service is used to guarantee a static amount of bandwidth. VBR service is designed for a wide range of applications, including real-time and non-real-time applications. GFR service is designed for applications that may require a minimum rate guarantee and can benefit from accessing additional bandwidth. [AF-TM-0121.000] Suzuki & Sumimoto Ed. Expires January 2001 [Page 27] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 6.4.2 IntServ/RSVP [RFC2205] [RFC2208] [RFC2210] [RFC2746] [RSVP-LSP] The integrated service, or IntServ for short, is a mechanism for providing QoS/SLA by admission control. RSVP is used to reserve network resources. The network needs to maintain a state for each reservation. The number of states in the network increases in proportion to the number of concurrent reservations. 6.4.3 DiffServ [RFC2474] [RFC2475] The differentiated service, or DiffServ for short, is a mechanism for providing QoS/SLA by differentiating traffic. Traffic entering a network is classified into several behavior aggregates at the network-edge and each is assigned a corresponding DiffServ codepoint. Within the network, traffic is treated according to its DiffServ codepoint. Some behavior aggregates have already been defined. Expedited forwarding behavior [RFC2598] guarantees the QoS, whereas assured forwarding behavior [RFC2597] differentiates traffic packet precedence values. 7. Criteria for Achieving Interoperability (To be written) 8. Security Considerations (To be written) 9. References [RFC2764] Gleeson, B., Heinanen, J., et al., "A Framework for IP Based Virtual Private Networks, " RFC2764, February 2000. [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPN, " RFC2547, March 1999. [RFC2684] Grossman, D. and Heinanen J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5," RFC2684, September 1999. [RFC2685] Fox B., Gleeson, B., "Virtual Private Networks Identifier," RFC2685, September 1999. [VPN-2547BIS] Rosen, E., Rekhter, Y., et al., "BGP/MPLS VPNs," Internet-draft <draft-rosen-rfc2547bis-01.txt>, May 2000. [VPN-REQ] Berkowitz, H., "Requirements Taxonomy for Virtual Private Networks," Internet-draft, October 1999. Suzuki & Sumimoto Ed. Expires January 2001 [Page 28] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 [VPN-VR] Ould-Brahim H. and Gleeson, B., "Network based IP VPN Architecture Using Virtual Routers," Internet-draft , March 2000. [VPN-EXT] Casey, L., "An extended IP VPN Architecture," , November 1998. [VPN-IPSEC] Touch, J., Eggert, L., "Use of IPSEC Transport Mode for Virtual Networks," , March 2000. [VPN-CRLDP] Houlik, P., Zhang, Z., Balaji, S., "Extensions to CR-LDP for VPNs," <draft-zhang-crldp-ext-for-vpn-00.txt>, March 2000. [VPN-INTER] Sumimoto, J., et al,. "MPLS VPN Interworking" Internet- Draft ," February 2000. [VPN-MPLS1] Heinanen, J., Rosen, E., "VPN support with MPLS," , March 1998. [VPN-MPLS2] Heinanen, J. and Gleeson, B., "MPLS Mappings of Generic VPN Mechanisms," Internet-draft , August 1998. [VPN-MPLS3] Jamieson, D., et al., "MPLS VPN Architecture," , August 1998. [VPN-MPLS4] Casey, L., et al., "IP VPN Realization using MPLS Tunnels," Internet-draft <draft-casey-vpn-mpls-00.txt>, November 1998. [VPN-MPLS5] Muthukrishnan K., Malis, A., "A Core MPLS IP VPN Architecture," Internet-draft , June 2000. [MPLS-ARCH] Rosen E., et al., "Multiprotocol Label Switching Architecture," Internet-draft <draft-ietf-mpls-arch-06.txt>, August 1999. [MPLS-FRAME] Callon, R., Swallow, J., et al., "A Framework for Multiprotocol Label Switching," <draft-ietf-mpls-framework-05.txt>, September 1999 [MPLS-ATM] Davie, B., et al., "MPLS using LDP and ATM VC Switching," Internet-draft <draft-ietf-mpls-atm-04.txt>, June 2000 [MPLS-DIFF] Awduche, O., et al., "MPLS Support of Differentiated Services," Internet-draft <draft-ietf-mpls-diff-ext-05.txt>, February 2000. Suzuki & Sumimoto Ed. Expires January 2001 [Page 29] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 [MPLS-GMNCL] GMN-CL home page: http://www.gmncl.ecl.ntt.co.jp/top_e.html [RFC2784] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)," RFC2784, March 2000. [GRE-EXT] Dommety, G., "Key and Sequence Number Extensions to GRE," Internet-draft , June 2000. [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," RFC2401, November 1998. [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header," RFC2402, November 1998. [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," RFC2406, November 1998. [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," RFC2409, November 1998. [RFC2453] Malkin, G., "RIP Version 2," RFC2453, November 1994. [RFC2328] Moy, J., "OSPF Version 2," RFC2328, April 1998. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC1195, December 1990. [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4),"RFC1771, March 1995. [RFC1965] Traina, P., "Autonomous System Confederations for BGP," June 1996. [RFC1966] Bates, T., "BGP Route Reflection: An alternative to full mesh IBGP," June 1996. [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities Attribute," RFC1997, August 1996. [RFC2858] Bates, T., Chandra, R., Katz, D., Rekhter, Y., "Multiprotocol Extensions for BGP-4," RFC2283, February 1998. [BGP-COM] Ramachandra, S., "BGP Extended Communities Attribute," Internet-draft , May 2000. [AF-TM-0121.000] "Traffic Management Specification Version 4.1," ATM Suzuki & Sumimoto Ed. Expires January 2001 [Page 30] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 Forum, March 1999. [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC2205, September 1997. [RFC2208] Mankin, A., et al., "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment," RFC2208, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC2210, September 1997. [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service," RFC2211, September 1997. [RFC2212] Shenker, S., Partridge, C., Guerin, R., "Specification of Guaranteed Quality of Service," RFC2212, September 1997. [RFC2207] Berger, L., O'Malley, T., "RSVP Extensions for IPSEC Data Flows," RFC2207, September 1997. [RFC2746] Terzis, A., et al., "RSVP Operation Over IP Tunnels," RFC2746, January 2000. [RSVP-LSP] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels," Internet-draft <draft-ietf-mpls-rsvp-lsp-tunnel-05.txt>, February 2000. [RFC2474] Nichols, K., et al., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC2474, December 1998. [RFC2475] Blake S., et al., "An architecture for Differentiated Services," RFC2475, December 1998. [RFC2597] Heinanen, J., et al., "Assured Forwarding PHB Group," RFC2597, June 1999. [RFC2598] Jacobsen, V., et al., "An Expedited Forwarding PHB," RFC2598, June 1999. [DIFF-TUN] Black, D., "Differentiated Services and Tunnels," Internet-Draft , February 2000. Suzuki & Sumimoto Ed. Expires January 2001 [Page 31] INTERNET-DRAFT A Framework for Network-based VPNs July, 2000 10. Authors' addresses Muneyoshi Suzuki NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Junichi Sumimoto NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: sumimoto.junichi@lab.ntt.co.jp Kosei Suzuki NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: suzuki.kosei@lab.ntt.co.jp Hiroshi Kurakami NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: kurakami.hiroshi@lab.ntt.co.jp Takafumi Hamano NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: hamano.takafumi@lab.ntt.co.jp Naoto Makinae NTT Information Sharing Platform Laboratories 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: makinae.naoto@lab.ntt.co.jp Kenichi Kitami NTT Information Sharing Laboratory Group 3-9-11 Midori-Cho, Musashino-Shi, Tokyo 180-8585 Japan Email: kitami.kenichi@lab.ntt.co.jp Suzuki & Sumimoto Ed. Expires January 2001 [Page 32]