Internet Engineering Task Force Chandrasekar Kathirvelu
INTERNET-DRAFT Karthik Muthukrishnan
Tom Walsh
Expires January 2002 Lucent Technologies
Andrew Malis
Vivace Networks, Inc.
Fred Ammann
COMMCARE telecommunications
July 2001
Hierarchical VPN over MPLS Transport
<draft-ietf-ppvpn-hiervpn-corevpn-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
This memo presents an approach for building hierarchical Virtual
Private Network (VPN) services. This approach uses Multiprotocol
Label Switching (MPLS). The central vision is for the service
provider to provide a virtual router service to other SPs without
participating in VPNs of those SPs.
1.0. Acronyms
Kathirvelu, et al. Expires January 2002 [Page 1]
INTERNET-DRAFT Hierarchical VPNs July 2001
ARP Address Resolution Protocol
CE Customer Edge router
LSP Label Switched Path
PNA Private Network Administrator
SLA Service Level Agreement
SP Service Provider
PE Service Provider Edge Device
SPNA SP Network Administrator
VPNID VPN Identifier
VR Virtual Router
VRL Virtual Router Link
VRC Virtual Router Console
P Provider Device
2. Introduction
This draft describes an approach for building Hierarchical IP VPN
services out of the backbone of the SP's network. We use the VR
model to describe the relationship among the VPNs, and MPLS Label
stacking to explain how the data is transported in the
hierarchical VPNs.An application of this technique enables the
aggregration of many regional or local service Provider VPN
networks across a Hierarchical VPN tunneling architecture.
The approach presented here does not require modification of any
existing routing protocols.
3. Hierarchical Relationship between VPNs
A simplified example that shows a hierarchical relationship
between Virtual Routed VPNs is shown in Figure 1. NOTE:
Hierarchies can be extended to more than two levels.
Hierarchical levels are designated numerically with the highest
level designated as 0. Lower hierarchical levels are designated
as Level 1, 2, etc. Higher level VPNs transport lower level VPNs.
So:
- LEVEL 0 represents the highest hierarchical level. A Level 0
VPN transports lower level VPNs but is not itself transported by
any other VPN;
- LEVEL 1 represents a VPN that is transported by a LEVEL 0 VPN
but is not itself transported across any lower or equal level VPN.
Kathirvelu, et al. Expires January 2002 [Page 2]
INTERNET-DRAFT Hierarchical VPNs July 2001
Level 1 VPNs | Level 0 VPN | Level 1 VPNs
| |
VPN x | | VPN x
------------| |-------------
VPN y | VPN A | VPN y
------------|======================|-------------
VPN z | | VPN z
------------| |--------------
| |
Figure 1. Hierarchical VPN Levels.
By assigning the VPNs depicted in this figure to different hierarchical
levels, a hierarchical relationship between the VPNs is created. For
example, the highest hierarchical level is designated as "Level 0". In
this example, VPN A is a level 0 VPN. Similarly, VPNs' X, Y and Z are
part of the next lowest hierarchical level, designated "Level 1". Data
within a Level 1 VPN is transported transparently across the Level 0
VPN.
A possible realization of a Hierarchical VPN (similar to that depicted
in Figure 1) can now be described using the VR model. This realization
does not assume a single Service Provider only is involved.
Specificically, in the examples which follow, SP1 and SP2 do not have to
be the same Service Provider. MPLS Label stacking techniques are used
to create the hierarchical levels and explain how the data is
transported.
Figure 2. shows an example of a Hierarchical VPN involving two Service
Providers. This example assumes that SP1 provides an international
backbone network that is utilized by SP2 to connect its geographically
isolated regional (or local) networks. In this example, SP2 is
providing two customer VPNs, X and Y. A two level Hierarchical VPN is
created to allow VPN X and VPN Y (i.e., level 1 VPNs in this hierarchy)
to be transported (at level 0) across VPN A.
Kathirvelu, et al. Expires January 2002 [Page 3]
INTERNET-DRAFT Hierarchical VPNs July 2001
+-+
+---| | VPN x
+-+ VPN x | +-+
| | ( ) A ( ) +-+
+-+-- ( ) ( )-----(SP2)---| |
( ) A ( ) (G) +-+ VPN y
( SP2 )-----( SP1 )
( B ) ( ) A ( ) +-+
( ) ( )------(SP2)---| | VPN y
+-+ | ( ) (F) +-+
| |-------+ | +-+
+-+ VPN y +--------------| | VPN x
+-+
Figure 2 Hierarchical VPN
Figure 3 expands the diagram to show the relationship between SP2 and
SP1. From this Figure 3. we can see that SP2 provides both end customer
VPNs (i.e., VPN x and VPN y) and SP2 must also know about the backbone
(i.e., VPN A) that it uses for transporting the hierarchy. On the other
hand, SP1 needs to be concerned with just the Level 0 VPN A.
VPN x
+---+ VRL ( VPN x=>VPN A)
---| |-----------+
| | |
+---+ +-+--+
| |==========> SP1 PE (B)
| | VPN A
+---+ +-+--+
| | |
----| |-----------+
+---+ VRL ( VPN y=>VPN A)
VPN y
Figure 3 Hierarchical Relationship of a VRL
Figure 3. also shows a relationship between a level 1 VPN (e.g., VPN X)
and a level 0 VPN (e.g., VPN A). A Virtual Router Link (VRL) is used
between the Level 1 and Level 0 VPNs. The VRL is explained in more
detail in the next section. In Figure 3. the hierarchical relationship
is shown by the directional arrow indication (i.e., VPN X => VPN A).
The lower level VPN X has an arrow pointing to the higher level VPN A,
as indicated by VPN X => VPN A.
Kathirvelu, et al. Expires January 2002 [Page 4]
INTERNET-DRAFT Hierarchical VPNs July 2001
4. Virtual Router Link
A VR can be connected to other VRs by a Virtual Router Link (VRL). Each
end of VRL is logically bound to a VR. From the perspective of the VR,
the VRL looks like one of its many links, some of which could be
physical links. The user can define a set of rules on this VRL to
control the relationship between two VPNs. This relationship could
be hierarchical or peering.
In the case of hierarchical VPNs, VRLs are configured between VRs with
one end as the upper end of the hierarchy and the other as the lower
end.
NOTE: investigation into whether VRLs can be extended to cover point-
to-point connections between VRs for control information exchange is for
further study.
5. Label Distribution
VPNs can use any label distribution protocol. The only restriction is,
within a specific VPN, the same protocol should be used in all its PE
devices, so that they can interwork. This is restricted by the nature of
the distribution protocol not by the VPNs.
Referring to Figure 2, SP1 provides the Level 0 VPN service (called VPN
A) to SP2(B/G/F). The label distribution operates independently in each
level of the VPN Hierarchy. Labels are distributed for the Level 0 VPN
separately from the labels that are distributed for the Level 1 VPN.
The following text describes the label distribution for each level of
the hierarchical VPN.
Level 0 (VPN A) Label Distribution:
The PEs of SP1 share the VPN A routing information between each other.
In other words, the reachability information of SP2 edge routers is
exchanged. LSP tunnels are set up in VPN A between the edge routers of
SP2. For example, an LSP tunnel from SP2 (edge router B) is created to
SP2 (edge router G).
Level 1 (VPN X) Label Distribution:
The PEs of SP2 share the VPN x routing information with each other. In
other words, the reachability information of the CE routers of VPN x is
exchanged. LSP tunnels are set up in VPN X between the CE routers in
SP2.
Usage of Penultimate Hop Popping (PHP) requires penultimate and top-most
labels to be allocated from the same label space (e.g., in this case the
Kathirvelu, et al. Expires January 2002 [Page 5]
INTERNET-DRAFT Hierarchical VPNs July 2001
allocation is from VPN A's label space). This implies in the case of
Hierarchical VPNs, that an additional label (i.e., the penultimate
label) will be necessary between the IGP label (i.e., top-most label)
for the PE and VPN destination label. This is shown in the next section
on Forwarding.
In this example, it is indicated that A2 is the label for SP2-CE(G) in
SP2-CE(B) and it is shown in the Forwarding section (Section 6.) how A2
is used. (see Figure 4.). This label is chosen from the VPN A Label
space.
Architecturally, Level 1 VPN Y and Y are connected to Level 0 VPN A by
a Virtual Router Link. Note that the edge routers of SP2 must have
knowledge of all three VPNs (i.e., VPN X, VPN Y, and VPN A). When the
VRL is configured for a hierarchical relationship , then the top
level VPN will allocate a label for each VRL, i.e., to each VPNs, from
its label space.
6. Forwarding
User data from the lower level VPNs (e.g. Level 1 in Figure 4) are
forwarded by the LSP tunnels of the upper level VPN (e.g. Level 0 in
Figure 4). The label encoding shown in Figure 4. is explained below.
Kathirvelu, et al. Expires January 2002 [Page 6]
INTERNET-DRAFT Hierarchical VPNs July 2001
VPN x/y/z Data
+-----+ +----+----+
|Data | | Lx2|Data|
+-----+ +----+----+
+----+----+-----+
| Ax2|Lx2 | Data|
+----+----+-----+
+----+----+-----+-----+
| A2 |Ax2 | Lx2 |Data |
+----+----+-----+-----+
Figure 4 Label Encoding
1. Customer data arrives at the VPN X CE router in SP2 (B) and is
encapsulated in a MPLS frame.
2. Label Lx2 is pushed on to the Label Stack. Lx2 is the peer VPN x CE
label used to forward VPN X data to VPN X CE router in SP2 (G).
3. Next Label Ax2 is pushed on to the Label Stack. Ax2 is the peer VPN
X attachment label with VPN A taken from VPN A's label space. This
label is used by VPN A to forward data on the SP2 (G) VRL between VPN A
and VPN X.
4. Finally Label A2 is pushed on to the Label Stack. This is the peer
VPN A label used to forward data from the VPN A SP2 (B) PE router to the
VPN A SP2 (G) PE router.
In summary, the complete LSP path therefore to move customer data on VPN
X from the SP2 (B) CE to the SP2 (G) CE is as follows: a) Transport
data across Level 0 (VPN A) using label A2; b) Transport data across the
VRL from Level 0 to Level 1 in SP2 (G) using label Ax2 c) Transport data
across Level 1 (VPN x) from SP2 (B) to SP2(G) using label Lx2
7. Security Considerations
Security as available in MPLS networks will be available and extended to
hierarchical VPNs.
8. Intellectual Property Considerations
Lucent technologies may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Lucent Technologies. Lucent
Kathirvelu, et al. Expires January 2002 [Page 7]
INTERNET-DRAFT Hierarchical VPNs July 2001
Technologies intends to disclose those patents and license them on
reasonable and non-discriminatory terms.
9. References
[Callon] Callon R., et al., "A Framework for Multiprotocol Label
Switching", work in Progress
[Fox] Fox, B. and B. Gleeson,"Virtual Private Networks
Identifier", RFC 2685, September 1999.
[Rosen2] Rosen E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", work in progress
[muthuk] K.Muthukrishnan, A.Malis "A Core MPLS IP VPN Architecture",
RFC 2917 September 2000.
10. Authors' Addresses
Karthik Muthukrishnan
Lucent Technologies
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-1368
EMail: mkarthik@lucent.com
Andrew Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Phone: (408) 383-7223
EMail: Andy.Malis@vivacenetworks.com
Chandrasekar Kathirvelu
Lucent Technologies
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-7116
EMail: ck32@lucent.com
Tom Walsh
Lucent Technologies
10 Lyberty Way
Westford, MA 01886
Phone: (978) 392-2311
EMail: tdwalsh@lucent.com
Kathirvelu, et al. Expires January 2002 [Page 8]
INTERNET-DRAFT Hierarchical VPNs July 2001
Fred Ammann
COMMCARE Telecommunications
Turmstrasse 8
CH-8952 Schlieren
Switzerland
Phone: +41 1 738 61 11
Email: fa@commcare.ch
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kathirvelu, et al. Expires January 2002 [Page 9]
