Internet Draft




Internet Engineering Task Force          M. Suzuki and J. Sumimoto (Ed.)
INTERNET-DRAFT                                                       NTT
Expires May 24, 2001                                            A. Malis
                                                   Vivace Networks, Inc.
                                                        K. Muthukrishnan
                                                     Lucent Technologies
                                                       November 24, 2000


                   A Framework for Network-based VPNs
                 <draft-suzuki-nbvpn-framework-02.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 operating 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
   an 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 an outline of the



Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 1]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   interface and MIB specifications and present criteria for achieving
   interoperability.

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).  Note that the document uses
   concepts and discussions in [RFC2764], but does not repeat the
   discussions therein.

   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 service is defined as a service that provides a network whose
   logical structure, such as addressing, reachability, and access
   control, is equivalent to part of or all of a conventional enterprise
   network using private facilities, it does not affect the logical
   structure in the rest of the enterprise network, and it is
   implemented with public network facilities.

   In particular, a VPN service that uses facilities of the Internet is
   called an IP VPN service.  Since IP VPN services are provided at
   lower costs and their service provisioning is more flexible than that
   of VPNs based on other technologies, various IP VPN implementations
   have been developed.

   IP VPN implementations 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 practical and commonly
   supported way of achieving interworking between an NBVPN of one
   technology and another NBVPN of another technology even though they
   have similar mechanisms.  Thus, early provision of such a solution is



Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 2]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   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
   the architecture and specifications of NBVPNs.

   This standardization work aims to avoid applying excessive
   constraints on 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].

   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 lower costs than with the uniform
     NBVPN implementation.

   o Benefits to customers



Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 3]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


     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 summarizes security
   considerations.

2. Assumed Services of NBVPNs

   This section describes assumed services of NBVPNs which are provided
   to user sites by the networks.  The purpose of discussing assumed
   services is to extract the requirements for mechanisms to be
   standardized for interoperable NBVPNs.  We do not intend to
   standardize these services for NBVPNs in any way.

2.1 Closed User Group (CUG)

   A closed user group (CUG) service provides communications between
   various specific user sites 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 CUG Interconnection

   A CUG interconnection service enables communications between specific
   CUGs or user sites belonging to other CUGs within the networks.
   Access control (including packet filtering and address translation)
   may be applied between CUGs according to policy.  Interconnection of
   CUGs performed in user sites is outside the scope of this document.

2.3 QoS/SLAs

   QoS/SLA services provide guaranteed and/or differentiated
   communications with NBVPN-specific SLAs covering loss rates, jitter,
   latency, and bandwidth etc.  Various classes of QoS are provided,
   although they may depend on the supporting technologies, e.g.,



Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 4]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   IntServ [RFC2211] [RFC2212], DiffServ [RFC2474] [RFC2475], or L2
   traffic engineering capabilities [AF-TM-0121.000].

2.4 Dynamic Routing

   A dynamic routing service enables the exchange of unicast routing
   information between user sites and an NBVPN using a 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 distributed from one user site to another.  This service
   is essential for multihomed user sites, in which the main purpose of
   multihoming is to improve reliability.

2.5 Multiprotocol Transport

   A multiprotocol transport service supports traffic carried between
   user sites using various different protocols.

2.6 NBVPN over Multiple SPs

   An NBVPN over multiple SPs service enables a single NBVPN to cover
   multiple SPs.

2.7 Multicast

   A multicast service replicates multicast packets forwarded from user
   sites in the networks and forwards them to multiple user sites.
   Multicast routing information is exchanged between user sites and an
   NBVPN using a multicast routing protocol.

2.8 Note on Data Security Service

   [RFC2764] discusses data security service which provides stronger
   security than that of the basic CUG service and which is supported by
   encryption and authentication.  In this framework document, it is not
   assumed for a NBVPN service for the following reasons.

   o If a user requires stronger security than that of the NBVPN
     service, it should be provided by a CPE-based security mechanism.
     This is because a network-based solution cannot ensure the security
     of access links between user sites and a network.

   o If stronger security is provided by a network-based mechanism, it
     is located at the edge of the SP network providing the NBVPN
     service.  Thus, security and NBVPNs service mechanisms are
     independent, because the security protocol layer is located on the
     protocol layer that provides NBVPN service.  Therefore, this
     security mechanism is not discussed in this framework.



Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 5]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   However, a similar security mechanism may be needed on the SP
   interworking interface of NBVPNs.  See sections 4.4.1 and 8 for
   details.

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 interfaces and MIBs 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.  The architecture is based on a real
   routed IP network.

                    +-------------------------------+
                    | MIBs and Management Framework |
                    +-------------------------------+
                                   |
  +------+ Access        Logical        Logical        Access +------+
  | User |  link  +----+  link   +----+  link   +----+  link  | User |
  | site |--------| LR |=========| LR |=========| LR |--------| site |
  +------+        +----+         +----+         +----+        +------+

                                                    LR: Logical router

                 Figure 3.1: Logical architecture model.





















Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 6]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


                +----+         Logical link        +----+       +----+
                |    |=============================| LR |-------+ US |
   +----+       |    |                             +----+       +----+
   | US +-------| LR |
   +----+       |    |         Logical link        +----+       +----+
                |    |=============================| LR |-------+ US |
                +----+                             +----+       +----+

   +----+       +----+      +----+     +----+      +----+       +----+
   | US +-------|    |      |    |     |    |======| LR |-------+ US |
   +----+       | LR |======|    |     |    |      +----+       +----+
   +----+       |    |      |    |     |    |
   | US +-------|    |      | LR |=====| LR |
   +----+       +----+      |    |     |    |
   +----+       +----+      |    |     |    |      +----+       +----+
   | US +-------| LR |======|    |     |    |======| LR |-------+ US |
   +----+       +----+      +----+     +----+      +----+       +----+

                                                         US: User site

                    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 Logical router

     A logical router supports router functions dedicated to a serving
     NBVPN.  It has the following functions.

     - Routing function: A logical router creates, modifies, and
       maintains entries in a routing table of the serving NBVPN using
       routing protocols.

     - Forwarding function: A logical router forwards IP packets within
       the NBVPN by looking up entries in the routing table.

     - Access control function: A logical router may control access
       (packet filtering and address translation) from other NBVPNs or
       from the Internet.

   o User site

     A user site is one or more subnetworks that are part of an NBVPN.




Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 7]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o Logical link

     A logical link is a connection (isolated from other NBVPNs and the
     Internet) between logical routers whose serving NBVPNs are
     identical.  A logical link is terminated by logical routers.

   o Access link

     An access link provides a user site 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 logical
     routers, and other devices constructing the concerned NBVPN and
     associated managing functions.
































Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 8]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 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.


         :      +--------------------------------------+      :
         :      |                                      |      : +------+
+------+ :      |               +------+            +------+  : |  CE  |
|  CE  | :      |               |      |            |      |  : |device|
|device| :      |               |  PE  |            |  PE  |  : |  of  |
|  of  | :  +------+ Tunnel :   |router|   : Tunnel |router|--:-|NBVPN |
|NBVPN |-:--|      |========:===|      |===:========|      |  : |  A   |
|  A   | :  |      |        :   +------+   :        +------+  : +------+
+------+ :  |  PE  |        :              :           |      :
+------+ :  |router|   Network-facing-side interface   |      :
|  CE  | :  |      |                :               +------+  : +------+
|device|-:--|      |================:===============|      |--:-|  CE  |
|  of  | :  +------+                :               |  PE  |  : |device|
|NBVPN | :      |          |                |       |router|  : |  of  |
|  B   | :      |   +------+------+   +-----+-----+ |      |  : |NBVPN |
+------+ :      |   |NMS for      |   |NMS for    | +------+  : |  B   |
         :      |   |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 Customer edge (CE) device

     A CE device is usually a router located at the edge of a user site.
     It may also be a host or hosts belonging to a subnetwork.  A CE
     device belongs to only one NBVPN, although it can reach other
     NBVPNs through a CUG interconnection service.  It is usually
     accommodated by a single PE router.  However, four types of double-
     homing arrangements, shown in Figure 3.4, must be supported.





Suzuki & Sumimoto Ed.       Expires May 2001                    [Page 9]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


                   +----------------                    +---------------
                   |                                    |
               +------+                             +------+
     +---------|  PE  |                   +---------|  PE  |
     |         |router|                   |         |router|   Network
     |         +------+                   |         +------+
  +------+         |                   +------+         |
  |  CE  |         |                   |  CE  |         +---------------
  |device|         |      Network      |device|         +---------------
  +------+         |                   +------+         |
     |         +------+                   |         +------+
     |         |  PE  |                   |         |  PE  |
     +---------|router|                   +---------|router|   Network
               +------+                             +------+
                   |                                    |
                   +----------------                    +---------------
  This type includes a CE device connected
  to a PE router via two access lines.
                  (a)                                  (b)

                   +----------------                    +---------------
                   |                                    |
  +------+     +------+                +------+     +------+
  |  CE  |-----|  PE  |                |  CE  |-----|  PE  |
  |device|     |router|                |device|     |router|   Network
  +------+     +------+                +------+     +------+
     |             |                      |             |
     | Backdoor    |                      | Backdoor    +---------------
     | link        |      Network         | link        +---------------
     |             |                      |             |
  +------+     +------+                +------+     +------+
  |  CE  |     |  PE  |                |  CE  |     |  PE  |
  |device|-----|router|                |device|-----|router|   Network
  +------+     +------+                +------+     +------+
                   |                                    |
                   +----------------                    +---------------

                  (c)                                  (d)

          Figure 3.4: Four types of double-homing arrangements.


   o Networks

     NBVPN services are provided by one or more networks to CE devices
     as members of the concerned NBVPN.  These networks support PE
     routers, tunnels, NMSs for customers and device MIBs.  In this
     document, "a network" means a single domain of an SP.  The NBVPN



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 10]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


     operation in a network is outsourced to an SP, but the whole NBVPN
     operation may be spread over multiple SPs.

   o Tunnel

     A tunnel is a connection between PE routers.  Multiple logical
     links defined in section 3.1 may be multiplexed into a single
     tunnel.  A number of IP tunneling protocols have been proposed, but
     in this document, three different 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 tunneling mechanism, LSPs implement
     tunnels and two multiplexing schemes are supported.  The first
     scheme uses two-layer label stacking of the MPLS.  In this scheme,
     the multiple logical links identified by second labels are
     multiplexed in the 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 encapsulation header [RFC2684].  In this
     scheme, the multiple logical links in the tunnel are identified by
     the CPCS-UU or VPN-ID field respectively.

     When GRE is used for the tunneling mechanism and the key field
     extension is supported, the logical links are identified by the key
     field.  Note that if the key field is not present, the tunnel
     supports only one logical link.  When IPsec is used, they are
     identified by the SPI field.

     Note that when the 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, a tunnel is identical to the
     tunnel that directly multiplexes logical links and does not include
     underlying tunneling mechanisms.

     Figure 3.5 illustrates logical link multiplexing.  Multiple logical
     links supporting connections for NBVPNs are multiplexed into a
     tunnel.  This arrangement allows multiplexing of logical links of
     different NBVPNs.












Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 11]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


    +-------------+                                  +-------------+
    |  PE router  |              Tunnel              |  PE router  |
    |             |  +----------------------------+  |             |
    |  +-------+  |  :                            :  |  +-------+  |
    |  | LR of |========================================| LR of |  |
    |  |NBVPN A|  |  :        Logical link        :  |  |NBVPN A|  |
    |  +-------+  |  :                            :  |  +-------+  |
    |  +-------+  |  :                            :  |  +-------+  |
    |  | LR of |========================================| LR of |  |
    |  |NBVPN B|  |  :        Logical link        :  |  |NBVPN B|  |
    |  +-------+  |  :                            :  |  +-------+  |
    |  +-------+  |  :                            :  |  +-------+  |
    |  | LR of |========================================| LR of |  |
    |  |NBVPN C|  |  :        Logical link        :  |  |NBVPN C|  |
    |  +-------+  |  :                            :  |  +-------+  |
    |             |  +----------------------------+  |             |
    +-------------+                                  +-------------+

                   Figure 3.5: Logical link multiplexing.


   o Provider edge (PE) router

     A PE router implements one or more logical routers.  It is usually
     located at the edge of an SP network.  It may terminate access
     links.  In this document, the virtual router (VR) [VPN-VR] and VPN
     routing and forwarding (VRF) tables [VPN-2547BIS] approaches are
     considered as methods of implementing logical routers in a PE
     router.

     VR is a technology for implementing a router function in a PE
     router.  A PE router may contain more than one VR and a VR supports
     only one NBVPN.  A logical router can be implemented with a VR.  A
     VR forwards user traffic from a CE device or another VR, which
     belonging to the same NBVPN, to another CE device or VR via an
     access or logical link respectively.  For the dynamic routing
     service described in section 2.4, a VR also forwards route
     information inside user sites, which is received from a CE device
     or another VR, to another CE device or VR as user traffic.

     The distinctive feature of this approach is that the current
     routing protocols are applicable between VRs or PE routers without
     any extensions or modifications.  Thus, it can be implemented
     without difficulty and managed simply.  However, an extension for a
     routing protocol between PE routers has been proposed to support
     auto-setup of tunnels and auto-discovery of PE router topology and
     NBVPN membership [VPN-BGP-VR].




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 12]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


     A VRF table is a packet routing and forwarding table and a user
     site corresponds to a VRF table.  In a PE router, each logical
     router can be implemented with an entity of routing protocol
     between PE routers whose processing is based on VRF tables.  Based
     on the route information of a VRF table in a PE router, user
     traffic received from a CE device or another PE router is forwarded
     to another CE device or PE router via an access or logical link
     respectively.  For the dynamic routing service, a PE router
     distributes route information inside user sites, which is received
     from a CE device or another PE router, to another CE device or PE
     router using routing protocol between PE routers.  See
     [VPN-2547BIS] for detail.

     This approach requires an extension of the route information format
     to distinguish the same IPv4 addresses belonging to different
     NBVPNs and an extension of the routing protocol between PE routers
     to distribute the extended route information.  Currently,
     extensions for BGP-4 protocol have been proposed.  Furthermore, for
     a dynamic routing service, when CE devices and PE routers in an
     NBVPN exchange route information inside user sites using OSPF, IS-
     IS, or RIP, and if different CE devices must belong to the same
     OSPF, IS-IS, or RIP domain, extensions which correspond to these
     protocols are required for the routing protocol between PE routers.

     However, in this approach, the number of routing protocol entities
     in a PE router does not depend on the number of NBVPNs supported by
     the PE router, so it achieves high scalability.  This approach
     assumes the use of LSP with two-layer label stacking as the
     tunneling mechanism, and basically, multiple logical links
     identified by second labels are multiplexed in the tunnel
     identified by the top label.  Therefore, the tunnel enables high-
     speed packet forwarding, because the forwarding processing does not
     refer to the second label which reflects the number of NBVPNs
     supported by the PE router.

     In this approach, a VRF table can support more than one NBVPNs, so,
     a user site is able to belong to multiple NBVPNs.  However, the
     overlapping address space between NBVPNs can be allocated only when
     the NBVPNs have no common user sites.  That is, if two NBVPNs have
     the common address space, a user site can belong to only one NBVPN.
     And if an NBVPN has a private address space and it is
     interconnected to the Internet via NAT, the user traffic must be
     forwarded to a CE device where the NAT is located.  Therefore in
     this case, this approach does not optimize routing paths in the
     network(s) providing the NBVPN.

   o NMS for customer MIB




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 13]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


     An NMS that manages customer MIBs of an NBVPN.

   o NMS for device MIB

     An NMS that manages device MIBs of an NBVPN.

3.3 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 3.6, different
   subnetworks may be implemented with different technologies.  In this
   case, a PE router 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 (SE)
   router.

    +-----------------------------------------------------------+
    | +-----------------+                   +-----------------+ |
    | |                 |                   |               +----+
   +----+Tunnel:      +----+Tunnel:      +----+Tunnel:      |    |
   |    |======:======|    |======:======|    |======:======| PE |
   |    |      :      |    |      :      |    |      :      |    |
   |    |   Intra-    |    | Subnetwork  |    |   Intra-    +----+
   |    | subnetwork  |    |interworking |    | subnetwork    | |
   | PE |  interface  | SE |  interface  | SE |  interface    | |
   |    |      :      |    |      :      |    |      :      +----+
   |    |      :      |    |      :      |    |      :      |    |
   |    |Tunnel:      |    |Tunnel:      |    |Tunnel:      | PE |
   |    |======:======|    |======:======|    |======:======|    |
   +----+      :      +----+      :      +----+      :      +----+
    | |        :        |         :         |        :        | |
    | +-----------------+                   +-----------------+ |
    | |<-Subnetwork(s)->|                   |<-Subnetwork(s)->| |
    |  implemented with                      implemented with   |
    | a uniform technology                 a uniform technology |
    |                                                           |
    +-----------------------------------------------------------+
    |<------------------------ Network ------------------------>|

                Figure 3.6: Intra-subnetwork interface and
                    subnetwork interworking interface.







Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 14]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


    +-----------------------------------------------------------+
    | +-----------------+                   +-----------------+ |
    | |                 |                   |               +----+
   +----+   Tunnel    +----+Tunnel:      +----+   Tunnel    |    |
   |    |=============|    |======:======|    |=============| PE |
   |    |             |    |      :      |    |             |    |
   |    |             |    |     SP      |    |             +----+
   |    |             |    |interworking |    |               | |
   | PE |             | IE |  interface  | IE |               | |
   |    |             |    |      :      |    |             +----+
   |    |             |    |      :      |    |             |    |
   |    |   Tunnel    |    |Tunnel:      |    |   Tunnel    | PE |
   |    |=============|    |======:======|    |=============|    |
   +----+             +----+      :      +----+             +----+
    | |                 |         :         |                 | |
    | +-----------------+                   +-----------------+ |
    | |<----Network---->|                   |<----Network---->| |
    |                                                           |
    +-----------------------------------------------------------+
    |<------------------------ Networks ----------------------->|

                  Figure 3.7: SP interworking interface.

   Similarly, when a single NBVPN spans multiple SPs, PE routers should
   be placed at every SP interconnecting point as shown in Figure 3.7.
   In this document, they are called inter-provider edge (IE) routers.

   In the rest of this document, SE and IE routers are also simply
   called "PE routers" unless they need to be differentiated.

   The intra-subnetwork interface and subnetwork interworking interface
   are defined as shown in Figure 3.6.  The former interface exists
   between a pair of PE routers and is restricted to one or more
   subnetworks implemented with a uniform technology.  The latter
   interface exists between a pair of SE routers and connects two
   subnetworks implemented with different technologies.  The SP
   interworking interface is defined as shown in Figure 3.7.  It exists
   between a pair of IE routers and connects two SP networks.

3.4 Targets of the Standardization Work and Protocol Architecture

   The targets of the standardization work are the following two
   interfaces and MIBs illustrated in the reference model given in
   Figures 3.3, 3.6, and 3.7.

   o Customer-facing-side interface

     An interface between a CE device and a PE router.



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 15]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o Network-facing-side interface

     An interface between PE routers.  This interface is further
     classified into the following three interfaces.

     - Intra-subnetwork interface

     - Subnetwork interworking interface

     - SP interworking interface

   o Customer MIBs

     MIBs of NBVPN customer attributes.

   o Device MIBs

     MIBs of device attributes, covering PE routers and other devices
     constructing the concerned NBVPN.

   To clarify the protocol architecture on the network-facing-side
   interface, protocols on the interface are classified into the u- and
   c-planes.

   The u-plane provides forwarding of user traffic between CE devices
   belonging to the same NBVPN.  For the dynamic routing service
   implemented with the VR approach, a VR forwards route information
   inside user sites to another VR as user traffic via a logical link.
   Therefore, this protocol is included in the u-plane.  Tunneling
   protocols that connect PE routers belong to the u-plane protocols.
   However, tunnel setup protocols are included in the c-plane.

   The c-plane provides auto-discovery of PE routers topology and NBVPN
   membership.  It also provides auto-setup of tunnels based on the PE
   routers topology information.  For the dynamic routing service
   implemented with the VRF approach, it provides distribution of route
   information inside user sites between PE routers.  Routing protocols
   between PE routers and control protocols for MPLS and IPsec belong to
   the c-plane.  Note that GRE is not equipped with standard ways to set
   up and maintain GRE tunnels.

4. Requirements for Interfaces and MIBs

4.1 General Requirements

   The implementation providing an NBVPN must:

   o be scalable



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 16]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   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 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.1.

   Note that not all protocols and MIBs specified in section 3.4 need to
   support all identifiers described in this section.  However,
   supported identifiers must be the same as, logically equivalent to,
   or inclusive of identifiers described in this section.

































Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 17]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


                  TUNNEL-ID                   TUNNEL-ID
              LLINK-ID|                           |LLINK-ID
           PE-ID  |   |                           |   |  PE-ID
             |    |   |                           |   |    |
    LPORT-ID |    |   |                           |   |    |
 CE-ID  |    |    |   |                           |   |    |
   |    |    V    |   V          Tunnel           V   |    V
   |    |  +----+ | +-+---------------------------+-+ | +----+
   |    |  |    | V :         Logical link          : V |    |
   V    |  |    |=+===================================+=|    |
 +----+ V  |    |   :         Logical link          :   | SE |
 |    | |  |    |=+===================================+=|    |
 | CE +-+--|    |   :                               :   |    |
 |    | |  |    |   +-+---------------------------+-+   +----+
 +----+    |    |
           |    |                Tunnel                     LPORT-ID
 +----+ |  | PE |   +-+---------------------------+-+   +----+  |  CE-ID
 |    +-+--|    |   :         Logical link          :   |    |  |    |
 |    | |  |    |=+===================================+=|    |  |    V
 |    |    |    |   :         Logical link          :   |    |  V +----+
 | CE |    |    |=+===================================+=|    |  | |    |
 |    |    |    |   :         Logical link          :   |    |--+-+ CE |
 |    | |  |    |=+===================================+=|    |  | |    |
 |    +-+--|    |   :                               :   |    |    +----+
 +----+ |  |    |   +-+---------------------------+-+   | PE |
           +----+                                       |    |
                                 Tunnel                 |    |    +----+
           +----+   +-+---------------------------+-+   |    |  | |    |
           |    |   :         Logical link          :   |    |--+-+ CE |
           |    |=+===================================+=|    |  | |    |
           | IE |   :         Logical link          :   |    |    +----+
           |    |=+===================================+=|    |
           |    |   :                               :   |    |
           +----+   +-+---------------------------+-+   +----+

                        Figure 4.1: 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.

   o VPN-ID, which identifies each NBVPN, must be unique at least within
     each SP's network.

   o CE-ID, which identifies each CE device, must be unique at least
     within each SP's network.



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 18]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o PE-ID, which identifies each PE router, must be unique at least
     within each SP's network.  The PE-ID of an IE 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 PE-ID.

   o LPORT-ID, which identifies a logical port, must be unique at least
     within each PE router containing the logical port.  Here, a logical
     port represents a terminating point of an access link accommodating
     a user site.

   o TUNNEL-ID, which identifies each tunnel, must be unique at least
     within each PE router supporting the tunnel.

   o LLINK-ID, which identifies each logical link, must be unique at
     least within each tunnel supporting the logical link.

   The scope of the identifiers is summarized in Figure 4.2.  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
           |
           +--> CE-ID
           |
           +--> PE-ID +--> LPORT-ID
                      |
                      +--> TUNNEL-ID ---> LLINK-ID

                     Figure 4.2: 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.

   o The CE-ID must be mapped to one or more pairs of PE-ID and LPORT-ID
     to configure the accommodation of CE devices.  Note that it is not
     necessary for the mapping to be built in a one-to-one manner
     because a CE device may be connected to PE routers through multiple
     access links as shown in Figures 3.4(a) and (b).  In this case, the
     CE-ID must be mapped to all the concerned pairs of PE-ID and LPORT-
     ID.



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 19]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o The CE-ID must be uniquely mapped to the VPN-ID to distinguish the
     NBVPN associated with the CE device.

   o A pair of PE-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 PE-ID, TUNNEL-ID, and LLINK-ID must be uniquely mapped to
     the VPN-ID to support a logical link.

4.3 Requirements for Customer-facing-side Interface

   This section describes the requirements for the customer-facing-side
   interface shown in Figure 3.3.

   o Packet encapsulation

     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 CE device and a
     PE router must support the specified QoS/SLA.

   o Dynamic routing

     For dynamic routing service, different routing protocols must be
     supported per access link connecting a CE device and a PE router.

4.4 Requirements for Network-facing-side Interface

   This section describes the requirements for the three specific
   network-facing-side interfaces shown in Figures 3.3, 3.6, and 3.7.

4.4.1 Requirements for protocols on u-plane

   o Packet encapsulation

     Every packet must be encapsulated with the LLINK-ID.  Multiprotocol
     transport service requires multiprotocol-over-IP encapsulation.

   o QoS/SLA

     For QoS/SLA service, every tunnel or logical link must support the
     specified QoS/SLA per NBVPN.  Note that if QoS/SLA support is per-
     tunnel based, it can support only one logical link.



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 20]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o Note on security

     If a tunnel on the SP interworking interface is not implemented
     with a direct circuit between IE routers and it passes through an
     unsecure SP, POP, NAP, or IX, then security mechanisms should be
     located at the edge routers.  However, this security and NBVPN
     service mechanisms are independent, so the detailed specifications
     of the security mechanism depend on the implementation.  See
     sections 2.8 and 8 for security discussions.

4.4.2 Requirements for protocols on c-plane

   o Tunnel setup and maintenance

     To set up tunnels between PE routers, every PE router must support
     static configuration for tunneling and may support a tunnel setup
     protocol.  When PE routers support the protocol, the information
     exchanged between them includes the VPN-ID, TUNNEL-ID, QoS/SLA
     information for QoS/SLA service, and multiprotocol-over-IP
     encapsulation information for multiprotocol transport service.

     A protocol for monitoring tunnel states must be supported.

     A protocol for tunnel restoration must be supported.

     For multicast service, multicast traffic must be forwarded through
     the created tunnels.

   o Auto-discovery of PE routers topology and NBVPN membership

     For auto-discovery of PE routers topology and NBVPN membership,
     extensions for routing protocol between PE routers may be needed.

     Routing protocols on the SP interworking interface may support
     authentication.

     If policy routing is performed, routing protocols running between
     IE routers on the SP interworking interface may specify
     intermediate SPs by SP-ID in route distribution and then routing
     protocols running between IE routers on the intra-subnetwork and
     subnetwork interworking interface may also specify intermediate SPs
     by SP-ID in route distribution.

   o Dynamic routing

     For dynamic routing service implemented with the VRF approach,
     routing protocols running between IE routers must support route
     control independently per NBVPN.



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 21]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


4.5 Requirements for Customer MIB

   This section describes the requirements for the customer MIB shown in
   Figure 3.3.

   o Management information about CE devices and customer attributes of
     NBVPN must be configured and maintained.  The information includes
     the CE-ID, PE-ID, LPORT-ID, VPN-ID, access control policy
     information for CUG interconnection service, routing protocols used
     for dynamic routing or multicast service, and QoS/SLA information
     for QoS/SLA service.

4.6 Requirements for Device MIB

   This section describes the requirements for the device MIB shown in
   Figure 3.3.

   o The configuration and maintenance of PE routers must be supported.
     Their management information includes IP routing information and
     access control policy information for CUG interconnection 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 TUNNEL-ID, LLINK-ID, tunnel states, and QoS/SLA information for
     QoS/SLA service.

   o Routing protocols running between PE routers and CE devices must be
     configured and maintained per NBVPN.  For multicast service,
     multicast routing protocols must also be supported.

   o Routing protocols running between PE routers must be configured and
     maintained.  For multicast service, multicast routing protocols
     must also be supported.

5. Outline of Interface and MIB Specifications

   (To be written)









Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 22]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


6. Survey of Available Technologies

   The technologies surveyed in this section are relevant to NBVPNs.
   The framework, however, neither compels nor excludes their use.

6.1 Tunneling

   Tunneling mechanisms provide isolated and secure communication
   between two CE devices.  Available tunneling mechanisms include (but
   are not limited to): MPLS [MPLS-ARCH] [MPLS-FRAME] [MPLS-ATM], GRE
   [RFC2784] [RFC2890], and IPsec [RFC2401] [RFC2402].  In an NBVPN, a
   tunnel is a secure communication path within a network.  A PE router
   encapsulates a data packet incoming from a CE device, and injects it
   into an appropriate tunnel.  The data packet traverses the network,
   and reaches the PE router on the far side.  In the course of
   traversal, the data packet may have transferred to other tunnels, if
   necessary.  The PE router then retrieves the data packet from a
   tunnel, and passes it to the destination CE device.

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 Multiprotocol transport

     MPLS can carry data packets other than IP ones.

   o QoS/SLA

     MPLS does not have intrinsic QoS or SLA management mechanisms.
     Some other techniques such as DiffServ may be used with it [DIFF-
     MPLS].

   o Tunnel setup and maintenance

     LSPs are set up and maintained by LDP (Label Distribution Protocol)
     or RSVP (Resource Reservation Protocol) [LSP-RSVP].



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 23]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     MPLS does not restrict the MTU size.  The overhead of label
     switching should be minimal.  MPLS guarantees in-order delivery of
     packets.

6.1.2 GRE [RFC2784] [RFC2890]

   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 GRE specification [RFC2784] does not support multiplexing.  But
     the key field extension to GRE is specified in [RFC2890] and it may
     be used as a multiplexing field.

   o Multiprotocol transport

     GRE is assumed to support any type of payload protocol.

   o QoS/SLA

     These capabilities depend on the delivery protocol.

   o Tunnel setup and maintenance

     GRE is not equipped with standard ways for setting up and
     maintaining GRE tunnels.

   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     These capabilities depend on the delivery protocol, but the GRE
     header overhead is designed to be minimal.  The sequence field
     proposed in [RFC2890] may be used to achieve in-order delivery.

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



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 24]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   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, either an AH or ESP header is inserted between the
   IPv4 header and the transport protocol header.  In tunnel mode, an IP
   packet is encapsulated with an outer IP packet header.  Either an AH
   or ESP header is 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 between PE routers.  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 Multiprotocol transport

     IPsec needs extensions to carry packets other than IP ones.
     Alternatively, GRE may be used with it.

   o QoS/SLA

     IPsec itself does not have intrinsic QoS/SLA capabilities.  Other
     mechanisms such as "RSVP Extensions for IPSEC Data Flows" [RFC2207]
     or DiffServ may be used with it.

   o Tunnel setup and maintenance

     IKE is used for the setup and maintenance of tunnels.

   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     IPsec does not restrict the MTU size.  IPsec may impose its own
     overhead.  IPsec has a sequence number field that is used by a
     receiver to perform an anti-replay check, not to guarantee in-order
     delivery of packets.

   Note: IPsec is applicable to a CPE-based VPN as well as to an NBVPN.
   This document deals with the aspects of IPsec that are relevant to an
   NBVPN.







Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 25]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


6.2 VPN Identifiers

   An NBVPN spanning multiple autonomous systems requires the use of a
   globally unique VPN identifier such as "a pair of an autonomous
   system-number and a VPN-index local to the 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 bits 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.

   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



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 26]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


     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 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.

     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.





Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 27]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   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
     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 (see section 6.3.1)

   o RIP (see section 6.3.1)

   o OSPF (see section 6.3.1)

   o BGP (see section 6.3.1)

   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."



Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 28]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   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 [AF-TM-0121.000]

   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.

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.







Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 29]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


7. Criteria for Achieving Interoperability

   (To be written)

8. Security Considerations

   As described in section 2.8, if a user requires stronger security
   than that of the basic CUG service, it should be provided by a CPE-
   based security mechanism.  This is because a network-based solution
   cannot ensure the security of access links between user sites and
   network.

   As described in section 4.4.1, if a tunnel on the SP interworking
   interface is not implemented with direct circuit between IE routers
   and it passes through an unsecure SP, POP, NAP, or IX, then security
   mechanisms should be located at the edge routers.  However, detailed
   specifications of this security mechanism depend on the
   implementation, so it is not discussed in this framework.

Acknowledgments

   VPNs are a huge technology and without the early work of RFC2764 "A
   Framework for IP Based Virtual Private Networks," it would have been
   impossible for us to complete this framework document.  We would like
   to thank the authors of RFC2764, especially Bryan Gleeson of Nortel
   Networks.

   We would also like to thank Joel Halpern of Longitude Systems, Eric
   Rosen of Cisco Systems, and Kazuo Kobayashi for their valuable
   comments and suggestions.

References

   [RFC2764] Gleeson, B. et al., "A Framework for IP Based Virtual
   Private Networks," RFC2764, February 2000.

   [RFC2547] Rosen, E. and 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. and Gleeson, B., "Virtual Private Networks
   Identifier," RFC2685, September 1999.

   [VPN-2547BIS] Rosen, E. et al., "BGP/MPLS VPNs," Internet-draft
   <draft-rosen-rfc2547bis-02.txt>, July 2000.




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 30]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   [VPN-BGP-OSPF] Rosen, E., "OSPF as the PE/CE Protocol in BGP/MPLS
   VPNs," Internet-draft <draft-rosen-vpns-ospf-bgp-mpls-00.txt>, July
   2000.

   [VPN-BGP-IPSEC] De Clercq, J. et al., "BGP/IPsec VPN," Internet-draft
   <draft-declercq-bgp-ipsec-vpn-00.txt>, July 2000.

   [VPN-BGP-VR] Ould-Brahim, H. et al., "BGP/VPN: VPN Information
   Discovery for Network-based VPNs," Internet-draft , July 2000.

   [VPN-VR] Ould-Brahim H. et al., "Network based IP VPN Architecture
   Using Virtual Routers," Internet-draft , July 2000.

   [VPN-IPSEC] Lordello, C. et al, "VPN-ID-Enhanced IPSec-VPN DOI for
   ISAKMP," Internet-draft , August
   2000.

   [VPN-INTER] Sumimoto, J. et al., "MPLS VPN Interworking" Internet-
   Draft <draft-sumimoto-mpls-vpn-interworking-00.txt>," February 2000.

   [RFC2917] Muthukrishnan, K. and Malis, A., "A Core MPLS IP VPN
   Architecture," RFC2917, September 2000.

   [MPLS-ARCH] Rosen E. et al., "Multiprotocol Label Switching
   Architecture," Internet-draft <draft-ietf-mpls-arch-07.txt>, July
   2000.

   [MPLS-FRAME] Callon, R. 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] Le Faucheur, F. et al., "MPLS Support of Differentiated
   Services," Internet-draft <draft-ietf-mpls-diff-ext-07.txt>, August
   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.

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE,"
   RFC2890, September 2000.




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 31]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


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

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

   [RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
   Payload (ESP)," RFC2406, November 1998.

   [RFC2409] Harkins, D. and 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. and Li, T., "A Border Gateway Protocol 4
   (BGP-4)," RFC1771, March 1995.

   [RFC1965] Traina, P., "Autonomous System Confederations for BGP,"
   RFC1965, June 1996.

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

   [RFC1997] Chandra, R., Traina, P., and Li, T., "BGP Communities
   Attribute," RFC1997, August 1996.

   [RFC2858] Bates, T., Chandra, R., Katz, D., and 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
   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.




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 32]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   [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., and Guerin, R., "Specification
   of Guaranteed Quality of Service," RFC2212, September 1997.

   [RFC2207] Berger, L. and 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-07.txt>, August 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.

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

10. Authors' addresses

   Muneyoshi Suzuki
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: suzuki.muneyoshi@lab.ntt.co.jp

   Junichi Sumimoto
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: sumimoto.junichi@lab.ntt.co.jp




Suzuki & Sumimoto Ed.       Expires May 2001                   [Page 33]

INTERNET-DRAFT     A Framework for Network-based VPNs     November, 2000


   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134, USA
   Email: Andy.Malis@vivacenetworks.com

   Karthik Muthukrishnan
   Lucent Technologies
   1 Robbins Road
   Westford, MA 01886, USA
   Email: mkarthik@lucent.com

   Kosei Suzuki
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: suzuki.kosei@lab.ntt.co.jp

   Hiroshi Kurakami
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: kurakami.hiroshi@lab.ntt.co.jp

   Takafumi Hamano
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: hamano.takafumi@lab.ntt.co.jp

   Naoto Makinae
   NTT Information Sharing Platform Labs.
   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 May 2001                   [Page 34]