Internet DRAFT - draft-balaji-mpls-csc-te-lsp-splice
draft-balaji-mpls-csc-te-lsp-splice
MPLS Working Group Bhargav Bhikkaji
Internet-Draft Balaji Venkat Venkataswami
Intended Status: Experimental RFC DELL
Expires: August 2013 Shankar Raman
Gaurav Raina
IIT Madras
February 25, 2013
An Architecture for splicing TE-LSPs in Hierarchical CsC scenarios
draft-balaji-mpls-csc-te-lsp-splice-02
Abstract
Hierarchical Carrier Supporting Carrier deployments involve a Carrier
Core which hereinafter is called the Tier-1 provider and two or more
VPN sites that are carriers themselves hereinafter called Tier-2
providers that offer MPLS VPN services to their own customers. In
such cases normally LDP is used to distribute labels amongst the
routers (P and PE devices) in the Tier-2 provider's sites. When RSVP
based TE-LSPs are constructed to explicitly route traffic for Tier-2
ISP's customers from the Tier-2 PEs to the CE of the Tier-1 provider
and such TE-LSPs exist on multiple sites of the Tier-2 provider, the
Tier-2 ISP may require splicing together through an "auto-match-and-
splice-together" facility such that traffic flows from the PE of the
Tier-2 ISP through the TE-LSP onto the CE of the Tier-1 ISP and then
onto the other site and takes a path through a specific TE-LSP from
the CE of the other site to the destination Tier-2 PE and then onto
the final customer.
This solution offers a lot of advantages such as providing adequate
assurance that the bandwidth for the traffic flowing through these
spliced TE-LSPs is met. It also provides a explicit routing of the
traffic rather than through the regular LDP (which follows IGP)
scenarios. Such explicitly routed TE-LSPs would have been constructed
taking into account factors such as using under-utilized links for
example. Splicing together these TE-LSPs in various sites and doing
the splicing on an auto-match based on bandwidth or delay metrics
would be a good service to offer to the Tier-2 ISPs customers.
This draft outlines a scheme that offers such a feature and service
to the Tier-2 ISPs through the addition of certain additional label
exchanges and some additional labels such as the RSVP-stitch label
and the RSVP-splicing-LDP label in the label stack which can be used
to splice together these tunnels. In case of re-optimization of the
LSP end-to-end there is a wide variety of choices for the near-end PE
to hook up with a suitable far-end tunnel in the other Tier-2 site.
Bhargav et.al. Expires August 2013 [Page 1]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
Explicit tunnel setup can be obviated by merely choosing from a set
of already constructed tunnels based on criterion that may involve
various parameters. Also fast-reroute in case of remote tunnel
failure is taken care of.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8
Bhargav et.al. Expires August 2013 [Page 2]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . 8
2.0 Constructing spliced TE-LSPs between the Tier-2 sites . . . 10
2.0.1 RSVP-splicing-LDP label . . . . . . . . . . . . . . . . 11
2.0.2 RFC 6511 applicability . . . . . . . . . . . . . . . . . 11
2.1 Decison at CE-B or the upstream CE in the Tier-2 ISP site. . 11
2.1.1 RSVP-stitch label . . . . . . . . . . . . . . . . . . . 12
2.2 Across the Carrier's Core . . . . . . . . . . . . . . . . . 12
2.3 Decision at PE-Lo . . . . . . . . . . . . . . . . . . . . . 12
2.4 Decision at CE-B . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Multiplicity of TE-LSP sections . . . . . . . . . . . . . . 13
2.6 Illustration . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Utility . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Tunnel Re-optimization by mere choice and not
reconstruction . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Fast-Reroute facility . . . . . . . . . . . . . . . . . . . 17
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 19
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Normative References . . . . . . . . . . . . . . . . . . . 19
5.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Bhargav et.al. Expires August 2013 [Page 3]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
1 Introduction
Some ISP customers of the MPLS/VPN backbone may want to provide
MPLS/VPN services for their own customers. These Tier-2 ISPs that we
will call them henceforth obtain the services for MPLS/VPN from a Top
level Carrier which we will henceforth call as a Tier-1 ISP for their
connectivity when these Tier-2 ISPs do not have networks that span
across the region, between geographical regions or across the globe.
This type of connectivity is known as hierarchical VPN sometimes
referred to as recursive VPN. Its deployment is similar to the other
Carrier's Carrier VPNs except Multi-protocol iBGP is introduced for
the distribution of the prefixes and label information between ISP
sites.
An example topology is provided below...
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer) ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| |
| MP-iBGP session between PE routers |
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( [PE-Pa]..).................................(...[PE-Lo] )
( Tier-2 ) and Label Exchange ( Tier-2 )
( ISP2 ) ( ISP2 )
( Site-A ) ______________________ ( Site-B )
((1) ) ( ) ( (2))
(______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________)
^ ( . . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
with LDP . ( ) . with LDP
Distribution ( Tier-1 ISP1 Core ) Distribution
(______________________)
Legend :
(1) IGP routes with LDP distribution
(2) IGP routes with LDP distribution
Figure 1: Reference Architecture Diagram
Within each Tier-2 ISP site in Figure 1 the PE-Routers PE-Pa and PE-
Lo hold VRF routing information for any VPN customers that are
attached to the POP at Paris and London. This is no different than
Bhargav et.al. Expires August 2013 [Page 4]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
the standard MPLS/VPN architecture so VPN-IPv4 prefixes are assigned
to customer VPN routes and are distribted between Tier-2 ISP sites
using MP-iBGP with BGP extended community attributes (Router Target
and Site of Origin).
Because each POP site for the Tier-2 ISP at London and Paris may hold
several PE routers a full mesh of MP-iBGP is necessary among all PE-
routers within the ISP MPLS/VPN topology. However again route
reflectors can be deployed to cut down on the number of required
peering sessions. In the example shown in Figure 1 it would be
possible for example for the Tier-2 ISP2 London and Paris PE-routers
to be route reflectors for their own Tier-2 ISP site. One could even
deploy totally separate devices and make each PE-router a route
reflector client so that MP-iBGP updates can be successfully
reflected to all PE-routers that need the VPN information contained
within the updates.
In the following figure 2 we provide an example of the relevant label
assignment for the 146.22.15.0/24 prefix which is learned from a VPN
customer of the Tier-2 ISP in the Paris area.
Bhargav et.al. Expires August 2013 [Page 5]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer)...146.22.15.0/24 ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| (2) |
(1)| MP-iBGP session between PE routers | (10)
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( [PE-Pa]..).................................(...[PE-Lo] )
( Tier-2 ) and Label Exchange ( Tier-2 )
( ISP2 (3) ) ( ISP2 )
( Site-A ) ______________________ ( Site-B )
((x) ) ( (7) ) ((y) (9))
(______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________)
^ ( . (5) (6) . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
with LDP . ( ) . with LDP
Distribution ( Tier-1 ISP1 Core ) Distribution
(4) (______________________) (8)
Legend :
(x) IGP routes with LDP distribution
(y) IGP routes with LDP distribution
Figure 2: Reference Diagram for normal control plane exchange for
HCsC
Legend for the control plane exchang3 is as follows :
(1) CE-Pa sends update for 146.22.15.0/24 to PE-Pa
(2) An MP-iBGP update for Net=146.22.15.0/24 with next hop as PE-Pa
and label assignment as 99 is sent to PE-Lo from PE-Pa
(3) An IGP + LDP update for Net=PE-Pa with label as pop action is
sent to CE-A from PE-Pa
(4) The CE-A device sends an update with Net=PE-Pa with NH=CE-A and a
label assignment of 1 to PE-X.
(7) An MP-iBGP update is sent from PE-X to PE-Y with Net=PE-Pa NH=PE-
X and Label as 4.
(5) An LDP update goes from PE-X with Net as PE-X and Label as pop
action to P1.
Bhargav et.al. Expires August 2013 [Page 6]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
(6) An LDP update goes from P1 with Net=PE-X and label as 2 to PE-Y
(8) An LDP update with Net=PE-Pa and NH=PE-Y with label as 3 from PE-
Y to CE-B.
(9) An IGP update goes from CE-B with Net=PE-Pa with NH as PE-Y to
PE-Lo
(10) An LDP Update goes from CE-B to PE-Lo with Net=PE-Pa and label
as 5.
The figure shows again that labels are advertised both within the
MPLS/VPN backbone and within each ISP site, for each of the Tier-2
ISP (Tier-1's customer) internal routes. ISP-customer (Tier-2
customer) external routes are distributed between the sites as VPN-
IPv4 routes. This mean that the iBGP session between sites becomes an
MP-iBGP session so that the VPN-IPv4 routes and associated labels can
be successfully advertised.
Bhargav et.al. Expires August 2013 [Page 7]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
The actual traffic flow for a packet destined for a host on the
146.22.15.0/24 subnet and arriving at the Tier-2 ISP's PE-Lo router
is illustrated in figure 2.
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer)...146.22.15.0/24 ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| |
(8)| MP-iBGP session between PE routers | (1)
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( [PE-Pa]..).................................(...[PE-Lo] )
( Tier-2 ) and Label Exchange ( Tier-2 )
( ISP2 (7) ) ( ISP2 )
( Site-A ) ______________________ ( Site-B )
( ) ( ) ( (2))
(______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________)
^ ( . (5) (4) . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
with LDP . ( ) . with LDP
Distribution ( Tier-1 ISP1 Core ) Distribution
(6) (______________________) (3)
Figure 2: Reference Diagram for normal Data Plane exchange for HCsC
(1) IP packet with IP-DA as 146.22.15.1
(2) Label packet with MPLS labels 5,99, IP-DA 146.22.15.1
(3) Label packet with MPLS labels 3,99, IP-DA 146.22.15.1
(4) Label packet with MPLS labels 2,4,99, IP-DA 146.22.15.1
(5) Label packet with MPLS labels 4,99, IP-DA 146.22.15.1
(6) Label packet with MPLS labels 1,99, IP-DA 146.22.15.1
(7) Label packet with MPLS labels 99, IP-DA 146.22.15.1
(8) IP packet with IP-DA as 146.22.15.1
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Problem Statement
Disparate ISPs or the same ISP could have multiple Tier-2 sites
Bhargav et.al. Expires August 2013 [Page 8]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
spread across geographies. This will entail that the these disparate
sites be interconnected through a Tier-1 ISP who has presence in
these disparate geographies and is willing to provide the
interconnect service for these Tier-2 sites.
Each Tier-2 site could have pre-built TE-LSPs that possess different
characteristic with respect to bandwidth, resource color, delay etc.
In order that these disparate sites be interconnected by using such
pre-built TE-LSPs through matching the characteristics of these TE-
LSPs appropriately between a pair of Tier-2 sites there exists a need
for a solution that exports RSVP-TE built TE-LSPs in the MP-iBGP /
MP-eBGP protocol between such sites through prior arrangement. The
solution also requires that such exported TE-LSPs are spliced
together with a Tier-1 ISP's Grand Forwarding Adjacency LSP which
spans across multiple areas of a Tier-1 ISP/ ISPs (in the case of
inter-AS).
Thus each Tier-2 site could have pre-built TE-LSP having different
characteristics such as
- available bandwidth characteristics
- Number of hops as a characteristic
- Delay bound characteristics.
Tier-2 sites do not have capability to choose TE-tunnel in respective
remote site based on such characteristics etc.. Similar need exists
for Inter-AS scenarios as well with the multiple Tier-1 ISPs serving
disparate Tier-2 sites.
RSVP-TE tunnels mechanisms are available at Inter-AS level. But there
are certain issues with them.
- These tunnels are setup end-to-end
- Requires administrative permissions across ASes
Security issues with respect to requesting LSPs to be setup in one
shot from PE in Tier-2 to PE in another Tier-2 is thus manifested.
Providers may have policies that prevent LSPs being setup right
through to their end customer facing PEs. In case of re-optimization
of the LSP end-to-end there is a wide variety of choices for the
near-end PE to hookup with a suitable far-end tunnel in the other
Tier-2 site. Explicit tunnel setup can be obviated by merely choosing
from a set of already constructed tunnels based on criterion that may
involve various parameters.
To overcome these issues the following draft provides a solution in
that problem statement's space.
Bhargav et.al. Expires August 2013 [Page 9]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
2.0 Constructing spliced TE-LSPs between the Tier-2 sites
It is possible that there be requirements to establish TE LSPs for a
variety of reasons between the PE routers in the Tier-2 sites for
example between PE-Lo and PE-Pa. These variety of reasons could
include Traffic engineering necessities that may arise for the sake
of allocating a certain amount of bandwidth for sets of traffic from
the Tier-2 customer sites or for guaranteeing a certain delay budget
or merely for utilizing under-utilized links (which otherwise would
not have been used if left to IGP paths).
Consider a situation where there exists requirements to establish TE-
LSPs between PE-Lo and PE-Pa for traffic direction from PE-Lo towards
PE-Pa.
These TE-LSP needs to traverse the Tier-1 ISP core. To traverse the
core it is possible to envisage that there exists sufficient
bandwidth between PE-X and PE-Y. One possibility is to establish a
TE-LSP between PE-X and PE-Y and use that LSP as a forwarding
adjacency LSP for carrying the traffic over the core. The other
possibility is to use normal LDP to carry the traffic over the core.
In both cases the TE-LSP established at the Tier-2 Customer sites
need to be spliced together. And that splicing should be done
automatically with reference to the characteristics that the TE-LSP
advertises. In case of using both schemes for traversing the core,
the TE-LSP in Site-B needs to be spliced to the section in Site-A.
Again it is possible that the section of the TE-LSP in Site-B was
constructed independently of Site-A TE-LSP section. The TE-LSP
section in Site-B being between PE-Lo and CE-B and the Site-A TE-LSP
section between CE-A and PE-Pa.
Now there has to be a mechanism of conveying the section information
between Site-A and Site-B. For traffic direction from Site-B to Site-
A the draft solution that we propose intends to convey this TE-LSP
information with TE-LSP characteristics such as bandwidth, delay,
cost et... through a MP-iBGP update from CE-A to CE-B. This mechanism
conveys the existence of a TE-LSP between PE-Pa and CE-A.
For the reverse direction of traffic the MP-iBGP update for the vice-
versa occurs.
In our case in the diagram Figure 3 the PE-Pa-to-CE-A TE-LSP is
advertised to CE-B. This information is thus sent from CE-A to CE-B.
This is sent thus as a MP-iBGP update. This MP-iBGP update is sent to
the PE-Pa and the PE-Lo Provider Edge routers as well. This is
required since the PE-Lo in our example can take a decision to use
Bhargav et.al. Expires August 2013 [Page 10]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
the TE-LSP or the normal LDP path at its end based on knobs
configured or based on certain policy decisions at that time of
sending the traffic where such policies could be configured. These
policy decisions could be built in as an algorithm with a set of
rules. This mechanism is outside the scope of the current document.
2.0.1 RSVP-splicing-LDP label
CE-B then generates two different labels towards PE-Y one for LDP and
another for RSVP-splicing-LDP. The LDP label is used when the packet
reaches CE-B towards PE-Y when the labels in the packet are LDP based
labels. If the packet arrives with a RSVP Label for the TE-LSP
between PE-Lo and CE-B at the head of the stack of labels at CE-B
then the RSVP-splicing-LDP label is used.
This also means that the MP-iBGP exchange between PE-X and PE-Y has
to have two classes of labels one for LDP and another for RSVP-
splicing-LDP.
Additionally PE-X to CE-A labels have to be of two kinds. One for LDP
and another for RSVP-splicing-LDP.
2.0.2 RFC 6511 applicability
For RSVP tunnels proposed in this mechanism it is important that non-
PHP behaviour be observed by the egress LSRs in the Carrier's core
and in the TE-LSP sections in the Tier-2 ISP as per [RFC6511].
2.1 Decison at CE-B or the upstream CE in the Tier-2 ISP site.
If the CE-B is our example has received MP-iBGP updates about the TE-
LSP at the remote site (CE-A to PE-Lo) it can take a decision as to
whether it has to use that TE-LSP or use an ordinary LDP based LSP by
choosing either the LDP label or the RSVP-splicing-LDP label. MP-iBGP
updates can be expected to keep the information of the TE-LSPs at the
remote Tier-2 site current by periodically but not too often updating
the information through a MP-iBGP update. This MP-iBGP update should
have characteristics of the TE-LSP at the remote end. The
characteristics relate to bandwidth and/or delay and/or MTU etc. The
exact set of characteristics would also include available bandwidth
on that TE-LSP. The end-point PE on the remote side connecting to the
Tier-2 ISP's customer is also part of the update. In our case the PE-
Pa and CE-B will know that to reach the 144.22.15.0/24 prefix there
exists a TE-LSP from CE-A to PE-Pa. The MP-iBGP update from CE-A
about the TE-LSP section from CE-A to PE-Pa also contains a label
called the RSVP-stitch label. This RSVP-stitch label will have to be
Bhargav et.al. Expires August 2013 [Page 11]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
imposed by the upstream CE-B at the Tier-2 ISP Site-B.
2.1.1 RSVP-stitch label
When the packet to 144.22.15.1 heads from PE-Lo towards CE-B, the
RSVP label for the TE-LSP to be used for that traffic is the topmost
label in the packet while the VPN instance label is the second label.
Assume that the PE-Lo has chosen to use the TE-LSP with the stitch
option in the remote Tier-2 site, then the packets are forwarded on
the TE-LSP as specified. At CE-B two things happen. The RSVP label at
the head of the stack of labels is swapped with the the RSVP-stitch
label.
An outer label is added which is the RSVP-splicing-LDP label
propositioned by PE-Y to CE-B instead of the regular LDP label. The
forwarding tables are spliced with the RSVP-splicing-LDP label to be
used if the incoming labeled traffic is exiting out of the RSVP
tunnel at CE-B with the RSVP-stitch label.
2.2 Across the Carrier's Core
This then carries the packet to PE-Y where the outer label which is
either a LDP label or a forwarding adjacency TE-LSP RSVP label is
added. This makes it four labels in the Carrier's core. Once the
packet reaches PE-X the RSVP-stitch label is exposed and the packet
is sent to the CE-A with the RSVP-splicing-LDP label at the top of
the stack. CE-A on receiving this has already stitched the forwarding
action for such a label in its forwarding table to pop the RSVP-
splicing-LDP label and swap the RSVP-stitch label so that the TE-LSP
section from CE-A to PE-Pa is used. The packet is then sent through
the TE-LSP section thereof. This action is programmed whenever a
RSVP-splicing-LDP label is the incoming label into the CE-A.
The packet then reaches the end of that TE-LSP section on to the
Tier-2 Provider's Site-A customer site.
2.3 Decision at PE-Lo
The decision to send the packets for a prefix through the TE-LSP at
Tier-2 Site-B is first made by PE-Lo since it has information that
TE-LSP between itself and CE-B exists and that there also exists a
TE-LSP section at Site-A between PE-Pa and CE-A.
2.4 Decision at CE-B
On arriving at CE-B the traffic is also subject to another decision
at the CE-B as to whether to use the LDP label or the RSVP-splicing-
LDP label. The latter would take the traffic through the TE-LSP
Bhargav et.al. Expires August 2013 [Page 12]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
section in Site-A of the Tier-2 ISP.
Thus policies can be enforced as per section 2.3 and/or 2.4. The
flexibility is left to the Tier-2 ISP administrator. The choice is
two-fold.
2.5 Multiplicity of TE-LSP sections
There could be multiple TE-LSP section between CE-A and PE-Pa. These
are conveyed through the MP-iBGP updates from CE-A to CE-B. For the
reverse direction of traffic the vice-versa applies. So CE-B in our
example could choose which one of these TE-LSP sections in Site-A
could be the most appropriate. A suitable decision algorithm may be
arrived at given the choices to be made at CE-B in our example.
2.6 Illustration
In other words to diagramatically illustrate the methodology
described above we provide the control and data plane exchanges for
the same...
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer)...146.22.15.0/24 ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| (2) |
(1)| MP-iBGP session between PE routers | (10)
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( .[PE-Pa]..).................................(...[PE-Lo] )
( .Tier-2 ) .TE-LSP section details and . ( Tier-2. )
( .ISP2 (3) ) .consequent Label Exchanges . ( ISP2 . )
( .Site-A ) . ______________________ . ( Site-B. )
( ........ ) . ( (7) ) . ( ..... (9))
(______[CE-A]..[PE-X] [PE-Y]---..[CE-B]________)
^ ( . (5) . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
RSVP-splicing ( ) . RSVP-splicing
-LDP Distrib. ( Tier-1 ISP1 Core ) . LDP Distrib.
(4) (______________________) (8)
Figure 3: Reference Diagram for proposed control plane exchange for
HCsC with stitch and splice TE-LSP method
Assumption is that there exist TE-LSP sections in Site-A and Site-B
Bhargav et.al. Expires August 2013 [Page 13]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
between CE-A and PE-Pa in the direction specified and between PE-Lo
and CE-B in that specified direction. Methods to adopt Non-PHP
behaviour at CE-B is to be implemented as per [RFC6511].
We demonstrate the use of the Tier-1 ISP core RSVP TE-LSP that ties
together the two TE-LSP sections in Site-A and Site-B in the data
plane example. This RSVP TE-LSP too has non-PHP behaviour for its
egress LSR PE-X for traffic in the London to Paris direction. The
same non-PHP behaviour for the RSVP TE-LSP between CE-A and PE-Pa is
also in vogue.
Legend for the control plane exchange is as follows :
(1) CE-Pa sends update for 146.22.15.0/24 to PE-Pa
(2) An MP-iBGP update for Net=146.22.15.0/24 with next hop as PE-Pa
and label assignment as 99 is sent to PE-Lo from PE-Pa
(2.1) An MP-iBGP update for TE-LSP section between CE-A to PE-Pa
describing a RSVP-stitch label 1000 with characteristics of Site-A
TE-LSP is sent to CE-B and PE-Lo.
(3) An RSVP TE-LSP between CE-A and PE-Pa with label as 500 with Non-
PHP behaviour is assumed to exist
(4) The CE-A device sends an LDP update with Net=PE-Pa with NH=CE-A
and a label assignment of 12 to PE-X where the label 12 is a RSVP-
splicing-LDP label. It also sends a normal LDP label for the same
FEC.
(7) An MP-iBGP update is sent from PE-X to PE-Y with Net=PE-Pa NH=PE-
X and Label as 4 where label 4 is identified as a RSVP-splicing-LDP
label.
(5) An RSVP forwarding Adjacency TE-LSP is assumed to exist between
PE-X and PE-Y from latter to former with non-PHP behaviour as per
[RFC6511]. The labels between PE-X and P1 is 2001 and PE-Y and P1 is
2000.
(8) An LDP update with Net=PE-Pa and NH=PE-Y with label as 11 from
PE-Y to CE-B where 11 is a RSVP-splicing-LDP label. There is also an
LDP update sent for normal LDP for the same FEC.
(9) An RSVP TE-LSP between PE-Lo and CE-B with label as 400 with non-
PHP behaviour is assumed to exist.
(10) null
Bhargav et.al. Expires August 2013 [Page 14]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer)...146.22.15.0/24 ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| |
(8)| MP-iBGP session between PE routers | (1)
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( [PE-Pa]..).................................(...[PE-Lo] )
( Tier-2 ) and Label Exchange ( Tier-2 )
( ISP2 (7) ) ( ISP2 )
( Site-A ) ______________________ ( Site-B )
( ) ( ) ( (2))
(______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________)
^ ( . (5) (4) . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
with LDP . ( ) . with RSVP-splicing
Distribution ( Tier-1 ISP1 Core ) ..LDP Distrib.
(6) (______________________) (3)
Figure 4: Reference Diagram for proposed Data Plane exchange for HCsC
splicing method
Assume TE-LSPs exist between PE-Lo and CE-B in Site-B and CE-A and
PE-Pa in Site-A. Also assume a forwarding adjacency LSP constructed
using RSVP exists between PE-Y and PE-X in the said direction from Y
to X.
(1) IP packet with IP-DA as 146.22.15.1
(2) Label packet with RSVP label 400,99, IP-DA 146.22.15.1
(3) Label packet with MPLS labels 11,1000,99, IP-DA 146.22.15.1
(4) Label packet with MPLS labels 2000,4,1000,99, IP-DA 146.22.15.1
(5) Label packet with MPLS labels 2001,4,1000,99, IP-DA 146.22.15.1
(6) Label packet with MPLS labels 12,1000,99, IP-DA 146.22.15.1
(7) Label packet with MPLS labels 500,99, IP-DA 146.22.15.1
(8) IP packet with IP-DA as 146.22.15.1
Bhargav et.al. Expires August 2013 [Page 15]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
_________ _________
( ) ( )
( ISP2 ) ( ISP2 )
( Customer)...146.22.15.0/24 ( Customer)
( Paris ) ( London )
( ) ( )
(_[CE-Pa]_) (_[CE-Lo]_)
| |
(8)| MP-iBGP session between PE routers | (1)
_____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______
( [PE-Pa]..).................................(...[PE-Lo] )
( Tier-2 ) and Label Exchange ( Tier-2 )
( ISP2 (7) ) ( ISP2 )
( Site-A ) ______________________ ( Site-B )
( ) ( ) ( (2))
(______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________)
^ ( . (5) (4) . ) ^
IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes
with LDP . ( ) . with LDP
Distribution ( Tier-1 ISP1 Core ) Distribution
(6) (______________________) (3)
Figure 5: Reference Diagram for Data Plane exchange for proposed
scheme with HCsC with LDP labels in the Carrier's Core.
Note : Control plane has not been shown for sake of brevity.
Assume TE-LSPs exist between PE-Lo and CE-B in Site-B and CE-A and
PE-Pa in Site-A. Also assume there is no forwarding adjacency LSP
constructed using RSVP exists between PE-Y and PE-X in the said
direction from Y to X. There are only LDP labels assigned in that
direction.
(1) IP packet with IP-DA as 146.22.15.1
(2) Label packet with RSVP label 400,99, IP-DA 146.22.15.1
(3) Label packet with MPLS labels 11,1000,99, IP-DA 146.22.15.1
(4) Label packet with MPLS labels 3000,4,1000,99, IP-DA 146.22.15.1
(5) Label packet with MPLS labels 4,1000,99, IP-DA 146.22.15.1
(6) Label packet with MPLS labels 12,1000,99, IP-DA 146.22.15.1
(7) Label packet with MPLS labels 500,99, IP-DA 146.22.15.1
(8) IP packet with IP-DA as 146.22.15.1
2.7 Utility
It is possible to envisage the following advantages as coming out of
this proposed architecture.
Bhargav et.al. Expires August 2013 [Page 16]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
o TE-LSPs in multiple sites may be needed to be spliced together.
o Such TE-LSPs may have been constructed to give a specific QoS for
select FECs / Prefixes.
o Without this scheme that ties the TE-LSP sections in multiple
sites together, traffic may pass through TE-LSP with a given QoS in
one site and may not pass through similar TE-LSP sections in other
sites.
o Splicing them together with a TE-LSP in the Tier-1 ISP gives the
traffic a complete QoS experience from start to finish.
o Multiple TE-LSP sections with different characteristics may exist
in multiple sites. As per MP-iBGP updates coming in the CE devices in
the Tier-2 ISP sites may choose one of them to provide the said QoS
to such traffic.
o The decision / choice to use either LDP in the sites and/or in the
Carrier's core may be done by suitable algorithms that sense
degradation in delay or bandwidth or a cost metric.
2.8 Tunnel Re-optimization by mere choice and not reconstruction
Through merely choosing from an available choice of multiple TE-
tunnel sections in the other Tier-2 site the appropriate far-end
tunnel can be hooked up with and re-signalling of the entire tunnel
can be obviated. By merely matching the characteristics with the
criterion applied a suitable label that will ensure choice of the
far-end tunnel can be applied. This does obviate the need for re-
construction of the tunnel in the far-end site. Suitable tunnels
could have been constructed a-priori for this very purpose before the
choice is made.
2.9 Fast-Reroute facility
A quicker fast re-route facility can be ensured if the BGP
advertisement of the TE-Tunnel in the far-end site withdraws it from
the near-end site. If the BGP advertisement is too late regular RSVP
messaging that is targeted at the head end of the tunnel could inform
such a head-end of the need to switch over to another tunnel and an
appropriate choice can be made of the suitable label to ensure this.
Alternate tunnels with their respective suitable labels to impose
could be chosen well in advance and the near-end PE in the Tier-2
site closest to the Tier-1 site could run a BFD session with the far-
end PEs in the far-end Tier-2 sites to check the health of the far-
end tunnel. When the BFD session fails and reports an error in the
Bhargav et.al. Expires August 2013 [Page 17]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
health of the far-end tunnel then the appropriate alternate far-end
tunnel could be chosen and a suitable label imposed at the near-end
to facilitate choice of the alternate far-end tunnel.
Bhargav et.al. Expires August 2013 [Page 18]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
3 Security Considerations
No additional security considerations exist except those that apply
already in the current specifications.
4 IANA Considerations
MP-iBGP PDU formats for TE-LSP characteristics and for passing the
RSVP-stitch label need to be added to this document.
Changes to LDP updates to indicate plain LDP labels and RSVP-
splicing-LDP labels need to be incorporated. A single bit or type /
code value needs to indicate whether the LDP label exchanged is
either a LDP label or a RSVP-splicing-LDP label.
These will be done in the future versions of the document.
5 References
5.1 Normative References
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
Bhargav et.al. Expires August 2013 [Page 19]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
5.2 Informative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, January 2007.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010.
[MPLSVPN-ARCH] Jim Guichard et.al, MPLS and VPN Architectures, ISBN-
1-58705-002-1
[RFC6511] Zafar Ali et.al, Non-Penultimate Hop Popping Behavior and
Out-of-Band Mapping for RSVP-TE Label Switched Paths
Authors' Addresses
Bhargav Bhikkaji
Dell-Force10,
350 Holger Way,
San Jose, CA
U.S.A
Email: Bhargav_Bhikkaji@dell.com
Balaji Venkat Venkataswami
Dell-Force10,
Olympia Technology Park,
Fortius block, 7th & 8th Floor,
Bhargav et.al. Expires August 2013 [Page 20]
INTERNET DRAFT Splicing TE-LSPs in Hierarchical CsC February 2013
Plot No. 1, SIDCO Industrial Estate,
Guindy, Chennai - 600032.
TamilNadu, India.
Tel: +91 (0) 44 4220 8400
Fax: +91 (0) 44 2836 2446
EMail: BALAJI_VENKAT_VENKAT@dell.com
Shankar Raman
Department of Computer Science and Engineering
IIT Madras,
Chennai - 600036
TamilNadu,
India.
EMail: mjsraman@cse.iitm.ac.in
Prof.Gaurav Raina
Department of Electrical Engineering,
IIT Madras,
Chennai - 600036,
TamilNadu,
India.
EMail: gaurav@ee.iitm.ac.in
Bhargav et.al. Expires August 2013 [Page 21]
