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]