Internet Draft






Internet Engineering Task Force                         Junichi Sumimoto
INTERNET-DRAFT                                          Muneyoshi Suzuki
Expires August 8, 2000                                               NTT

                                                            Osamu Tabata
                                                           Atsushi Iwata
                                                         NEC Corporation

                                                            Yutaka Ezaki
                                                           Masami Doukai
                                                         Fujitsu Limited

                                                        February 8, 2000


                         MPLS VPN Interworking

             <draft-sumimoto-mpls-vpn-interworking-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

   We call virtual private networks (VPNs) based on Multiprotocol Label
   Switching (MPLS) "MPLS VPN".  This document discusses motivation and
   a model of interworking among MPLS VPNs. It then proposes functional
   capabilities for the interworking such as realization of security,
   mapping of the QoS class, dynamic routing information distribution.



Sumimoto                  Expires August 2000                   [Page 1]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


   Considering easy provisioning, we focus on an interworking where each
   MPLS network is once terminated and IP header look-up is executed at
   an egress/ingress Label Switching Router (LSR), and IP over ATM
   (RFC1483) is used for interworking connections.

1. Introduction

   MPLS enables the forwarding of IP packets under the control of a
   standard IP routing algorithm, but the forwarding process does not
   use the IP packet header directly.  Instead, a short, fixed-length
   label is used to enable packet forwarding.  We call VPNs based on
   MPLS "MPLS VPN".  A number of MPLS VPN solutions (including pre-
   standard solutions) have been proposed and developed, where the
   interface between a user and a provider is IP.  These include BGP/VPN
   [RFC2547], GMN-CL [GMN-CL] and [COREVPNARCH].  But there is no
   agreement for interworking among MPLS VPNs.  VPN architecture based
   on MPLS is already under discussion in ITU-T SG13 [I.IPATM].

   We therefore discuss the following:
      - Motivation for interworking among VPNs (Section 2)
      - Assumptions of MPLS VPNs as elements for interworking
        (Section 3)
      - Functional capabilities for interworking such
        as realization of security, mapping of the QoS class,
        dynamic routing information distribution (Section 4)

2. Motivation for interworking among MPLS VPNs

   (1) VPNs spread over multiple differently implemented MPLS networks
   owned by different VPN service providers.  This follows the normal
   requirement and expectation that each VPN service provider chooses
   its best VPN implementation out of multiple vendors' implementations.

   (2) VPNs spread over multiple differently implemented MPLS networks
   owned by a VPN service provider. A VPN service provider may deploy
   multiple MPLS networks (e.g., an old MPLS network and a new MPLS
   network).  The VPN interworking removes the requirement that the all
   user sites of one VPN need to be connected to an MPLS network.

   In both cases, the interworking enable VPN service providers to make
   flexible provisioning of VPN services. It is of benefit to VPN users
   as well.

3. Assumptions

3.1 MPLS Network

   The following MPLS network structure [MPLSARC] is assumed to be



Sumimoto                  Expires August 2000                   [Page 2]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


   present as a base to provide VPN services.

                        +--------------------+
                        |                    |
                  +-----+  Backbone Network  +-----+
   User sites -+--| LSR |  implementing MPLS | LSR |--+- User sites
                  +-----+                    +-----+
                        |                    |
                        +--------------------+

                  Figure 1.  Structure of MPLS Network

3.2 MPLS VPN

3.2.1 Security support

   Each user-side logical/physical port of an ingress/egress LSR belongs
   to only one VPN. Traffic between any pair of such ports that belong
   to a VPN is isolated from traffic of any other VPNs, so a host of a
   user site belonging to any other VPNs is not permitted to send any
   packets to the VPN.

   For example, the following mechanisms realize the traffic isolation
   in an MPLS backbone network.

      - At each egress/ingress LSR, each VPN is managed by a number,
        label, or identifier.  In some implementations, each VPN is
        identified by an label (LSP), while in the other
        implementations, each VPN is identified by an number or
        identifier [VPNID] that is explicitly attached to packets in
        the MPLS network.

3.2.2 QoS class support

   The MPLS VPN supports QoS classes, for example, Assured Forwarding
   (AF) Classes of diffserv [RFC2475].
   A QoS class of each packet is identified by attributes concerning the
   logical/physical interface of the egress/ingress LSR, source and/or
   destination IP address, port number, diffserv codepoint, and so on.
   The backbone network between an ingress LSR and an egress LSR
   controls QoS based packet forwarding.

3.2.3 Dynamic routing information distribution

   An MPLS network can dynamically distribute the routing information of
   each VPN (1)within the MPLS network and (2)between the MPLS network
   and a user site.  Scope of the distribution is restricted within each
   VPN by the security support (See section 3.2.1).



Sumimoto                  Expires August 2000                   [Page 3]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


4. Proposed Model, Functional Capabilities for Interworking among MPLS
   VPNs

4.1 Interworking Model

               +---------+                    +---------+
VPN A          |         |                    |         |          VPN A
+----------------------------------------------------------------------+
|          +---+         +---+            +---+         +---+          |
|User site |   | Element |   |            |   | Element |   | User site|
| of VPN A-|   |    W    |   |            |   |    X    |   |- of VPN A|
|          |   |         |   |            |   |         |   |          |
+----------------------------------------------------------------------+
           |   |         |   |Interworking|   |         |   |
           |LSR|         |LSR|-----++-----|LSR|         |LSR|
           |   |         |   | Interface  |   |         |   |
+----------------------------------------------------------------------+
|          |   |         |   |            |   |         |   |          |
|User site-|   | Element |   |            |   | Element |   |-User site|
| of VPN B |   |    Y    |   |            |   |    Z    |   |  of VPN B|
|          +---+         +---+            +---+         +---+          |
+----------------------------------------------------------------------+
VPN B          |         |                    |         |          VPN B
               +---------+                    +---------+
             MPLS Network 1                  MPLS Network 2

                      Figure 2. Interworking Model

We call each part of a VPN that is cut by an MPLS network 'element'.

4.2 Functional Capabilities for Interworking

There are the following two types of interworking.

   (1)Interworking where each MPLS network is once terminated
      and IP header look-up is executed at an egress/ingress LSR.

   (2)Interworking without IP header look-up at an egress/ingress
      LSR.

As each existing MPLS VPN is implemented in unique manner, it is
difficult to realize type (2).  Type (1) is easy to provision since it
utilize the LSR's function of IP header look-up.  Therefore, we focus on
type (1).

We assume that the connections at the interworking interface are
provided by IP over ATM (RFC1483) since IP over ATM has advantage for
bandwidth control per logical connection. Use of other layer 2 protocol



Sumimoto                  Expires August 2000                   [Page 4]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


other than ATM and use of MPLS shim header is for further study.  These
connections are assumed to convey routing protocol packets as well as
data packets of each VPN.  No assumptions about which flavor of VPNs is
run on the other side is required.

We propose the following three functional capabilities, which are
required to support MPLS VPN interworking.

   - Realization of security
   - Mapping of the QoS class
   - Dynamic routing information distribution

in section 4.3, section 4.4, section 4.5, respectively.

4.3 Realization of Security

Each end of each connection is assigned an MPLS VPN of MPLS network that
is connected to the end of the connection.  Any packets are not
permitted to transmit between the connection and any unassigned MPLS
VPNs.  This mechanism result in realization of security.  The procedures
by which such an assignment is established are specific to the solution
used by the MPLS network implementation associated with the connection.
The identity of VPN at each end is meaningful only in the context of the
specific MPLS network associated with the connection.  We assume
multiple VPNs do not share one connection.

See figure 2.  There used a logical connection between the MPLS network
1 and MPLS network 2 for constructing a VPN over both MPLS network 1 and
MPLS network 2.  The connection for the VPN A is assigned to element 'W'
and 'W' is meaningful only in the context of MPLS network 1. The other
side of the connection is assigned to element 'X' and 'X' is meaningful
only in the context of MPLS network 2.

Note.  We recommend that bandwidth of a connection does not interfere
with bandwidth of any other connections. Detailed QoS specifications of
the connection are for further study.

4.4 Mapping of the QoS class

Attributes of a QoS class may be also assigned to each connection.  This
enables provisioning of multiple QoS classes within each VPN.  QoS
control is easy and only one-time class identification in the IP layer
is needed.








Sumimoto                  Expires August 2000                   [Page 5]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


            +-----------+                         +-----------+
      +-----+           +-----+             +-----+           +-----+
      |     +-----------+     |             |     +-----------+     |
      |     |  Element  |     |-------------|     |  Element  |     |
      | LSR |           | LSR |-------------| LSR |           | LSR |
      |     |     W     |     |-------------|     |     X     |     |
      |     +-----------+     | Connections |     +-----------+     |
      +-----+           +-----+     for     +-----+           +-----+
            +-----------+        different        +-----------+
           MPLS network 1       QoS Classes       MPLS network 2

       Figure 3. Using multiple connections for multiple QoS classes
                                for each VPN

     There is another optional method.
     We can use CoS, a bit-pattern in a field such as EXP of Shim header
     or TOS of an IP header, to identify a QoS class during packet
     transmission on the connection.  The connection is shared by
     multiple QoS classes.  A typical example of this mapping method is
     diffserv.  This method can reduce the number of connections, while
     QoS control on the connection is difficult.


            +-----------+                         +-----------+
      +-----+           +-----+             +-----+           +-----+
      |     +-----------+     |             |     +-----------+     |
      |     |  Element  |     |             |     |  Element  |     |
      | LSR |           | LSR |-------------| LSR |           | LSR |
      |     |     W     |     |             |     |     X     |     |
      |     +-----------+     |  Connection |     +-----------+     |
      +-----+           +-----+  supporting +-----+           +-----+
            +-----------+           CoS           +-----------+
           MPLS network 1                         MPLS network 2

     Figure 4. Using CoS for supporting multiple QoS classes for each VPN

4.5 Dynamic routing information distribution

     Some mechanisms for routing control per VPN are required in each
     egress/ingress LSR.  The connection between MPLS network 1 and MPLS
     network 2 just transmit packets of standard IP routing.  Then
     routing information is forwarded by the functional capability
     described in chapter 4.3 as well as data.  This enables dynamic
     routing information distribution within each VPN.  One of standard
     routing protocols such as BGP, OSPF, RIP, DVMRP, PIM can be used on
     the connections for every VPN.

4.6 Summary



Sumimoto                  Expires August 2000                   [Page 6]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


     Figure 5 summarize functional capabilities for MPLS VPN
     interworking with IP over ATM.  Note that this document does not
     require any new protocols or new label modification of existing
     protocols.


           +------------+                      +------------+
VPN A      |            |                      |            |      VPN A
+----------------------------------------------------------------------+
|      +---|            |---+    VC for    +---|            |---+      |
|      |   |   Data &   |   |  QoS class 1 |   |   Data &   |   |      |
|      |   |   routing  |---|------++------|---|   routing  |   |      |
|User--|---|<- inform ->|   |              |   |<- inform ->|---|--User|
|site  |   |   -ation   |---|------++------|---|   -ation   |   |  site|
|      |   |            |   |    VC for    |   |            |   |      |
|      |   |  Element W |   |  QoS class 2 |   | Element X  |   |      |
+----------------------------------------------------------------------+
       |   |    /|      |   |     /|       |   |    /|      |   |
       |   |     |      |   |      |       |   |     |      |   |
       |LSR| Prohibited |LSR|  Prohibited  |LSR| Prohibitd  |LSR|
       |   | to Transmit|   |  to Transmit |   | to Transmit|   |
       |   |     |      |   |      |       |   |     |      |   |
       |   |     |/     |   |      |/      |   |     |/     |   |
+----------------------------------------------------------------------+
|      |   |            |   |    VC for    |   |            |   |      |
|      |   |   Data &   |   |  QoS class 1 |   |   Data &   |   |      |
|      |   |   routing  |---|------++------|---|   routing  |   |      |
|User--|---|<- inform ->|   |              |   |<- inform ->|---|--User|
|site  |   |   -ation   |---|------++------|---|   -ation   |   |  site|
|      |   |            |   |    VC for    |   |            |   |      |
|      +---|  Element Y |---+  QoS class 2 +---| Element-Z  |---+      |
+----------------------------------------------------------------------+
VPN B      |            |          ||          |            |      VPN B
           +------------+     Interworking     +------------+
           MPLS Network 1       Interface      MPLS Network 2

        Figure 5. Proposed VPN Interworking by using IP over ATM

This document focuses on static interworking (i.e. user-plane
interworking) to deploy quickly.  Dynamic interworking (i.e. control-
plane or management-plane interworking) should be discussed in another
document to reduce manual configuration in near future.

5. Acronyms







Sumimoto                  Expires August 2000                   [Page 7]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


      CoS     Class of Service
      ISP     Internet Service Provider
      LSP     Label Switched Path
      LSR     Label Switching Router
      MPLS    Multiprotocol Label Switching
      OPS     Operation System
      QoS     Quality of Service
      VPN     Virtual Private Network

6.  References


   [RFC1483]  Heinanen J., "Multiprotocol Encapsulation over ATM Adaptation
       Layer 5," RFC1483.

   [VLAN] IEEE 8.2.1Q.

   [RFC2547] Rosen E. and Rekhter Y., "BGP/MPLS VPNs," RFC2547.

   [GMN-CL] GMN-CL home page: http://www.gmncl.ecl.ntt.co.jp/top_e.html

   [COREVPNARCH] Muthukrishnan K., et al, "Core MPLS IP VPN Architecture",
       draft-muthukrishnan-mpls-corevpn-arch-00.txt.

   [I.IPATM] ITU-T, "Transport of IP over ATM in Public Networks," Draft
       recommendation, I.ipatm, September, 1999.

   [MPLSARC] Rosen E., et al, "Multiprotocol Label Switching
       Architecture," draft-ietf-mpls-arch-06.txt.

   [VPNID] Fox B., et al, "Virtual Private Networks Identifier,"
       RFC2685.

   [RFC2475] Blake S., et al, "An architecture for Differentiated
       Services," RFC2475.

   [MPLSVPN] Jamieson D., et al, "MPLS VPN Architecture,"
       draft-jamieson-mpls-vpn-00.txt.













Sumimoto                  Expires August 2000                   [Page 8]

INTERNET-DRAFT           MPLS VPN Interworking          February 8, 2000


7. Authors' address

   Junichi Sumimoto
   NTT (Nippon Telegraph and Telephone Corporation)
   Information Sharing Platform Laboratories
   9-11, Midori-Cho  3-Chome
   Musashino-Shi,  Tokyo  180-8585  Japan

   Email: sumimoto.junichi@lab.ntt.co.jp

   Muneyoshi Suzuki
   NTT (Nippon Telegraph and Telephone Corporation)
   Information Sharing Platform Laboratories
   9-11, Midori-Cho  3-Chome
   Musashino-Shi,  Tokyo  180-8585  Japan

   Email: suzuki.muneyoshi@lab.ntt.co.jp

   Osamu Tabata
   NEC Corporation
   1753 Shimonumabe, Nakahara-ku,
   Kawasaki-shi, Kanagawa 211-8666

   Email:tabata@trd.tmg.nec.co.jp

   Atsushi Iwata
   NEC Corporation
   C&C Media Research Laboratories
   4-1-1 Miyazaki Miyamae-ku, Kawasaki
   Kanagawa, 216-8555 Japan

   E-mail: iwata@ccm.CL.nec.co.jp

   Yutaka Ezaki
   IP Network Systems Lab., Fujitsu Limited
   4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki
   211-8588, Japan

   E-mail: ezaki@flab.fujitsu.co.jp

   Masami Doukai
   Switching Node Systems Div., Network Systems Group, Fujitsu Limited
   2-12-5 Shimokodanaka, Nakahara-ku, Kawasaki
   211-0041, Japan

   E-mail: doukai@ss.ts.fujitsu.co.jp





Sumimoto                  Expires August 2000                   [Page 9]