INTERNET DRAFT
Expiration Date: March 2003
Vijayanand C
HCL Technologies
LSP Subobject for RSVP-TE
draft-vijay-mpls-rsvpte-lspsubobject-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 document describes the use of RSVP-TE[RSVP-TE] to establish
hierarchical tunnels using a LSP sub-object in the ERO.
This document proposes extensions to existing RSVP-TE for
establishing hierarchical tunnels in RSVP-TE using a LSP subobject
in the Explicit route object of RSVP-TE path message. LSP subobject
can be used to uniquely identify the outer tunnel to be used for
tunneling. This is useful in situations where the outer tunnel is
not an FA-LSP and the knowledge of outer tunnel is available to the
administrator.
1. Introduction
MPLS serves as a high speed switching mechanism which leverages
existing layer 2 protocols with popular layer 3 routing protocols
and serves to establish a common control and management plane.
RSVP-TE is an extension of RSVP[RSVP] for establishing traffic
engineered LSPs across the network to meet the needs of real-time
applications and QoS conscious applications. Tunneling of LSPs using
Vijayanand C [Page 1]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
pre-established LSPs is done to transparently transport data across
by using the label stack in the tunnel.
This document describes the use of RSVP-TE to establish nested
LSPs without the need for advertising the outer tunnel LSP as FA-
LSPs as described in MPLS-FA-LSP[FA-LSP]. The LSP ingress, after
computing the path for the LSP can use an existing LSP as a hop
along the path by mentioning it as a hop in the ERO of RSVP-TE path
message to establish the LSP. This is very useful when the LSP to be
established is not an FA-LSP and the knowledge of the LSP is
available to the administrator. The administrator needs to be aware
of the LSP parameters and bandwidth remaining in the LSP that is
used for tunneling.
2. 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 RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [RSVP-
TE]
LSR - Label Switch Router
LSP - An MPLS Label Switched Path
FA-LSP - A Forwarding Adjacency LSP. An LSP which is
advertised as a link into the Layer 3 routing protocol
Ingress - The LSR node which is the start of an LSP
Egress - The LSR node which is the finish of an LSP
Splicing - Joining two LSPs
Nesting - Using an LSP within another LSP
Label stacking - Using a stack of labels, one above the other
with the outermost label used for switching in the present
domain
Outer Tunnel - The LSP which is used for tunneling through.
Inner Tunnel - The LSP which tunnels through the outer tunnel.
ERO - Explicit route object appearing in RSVP-TE messages
Vijayanand C October 2002 [page 2 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
3. RSVP-TE Extensions
A new subobject - LSP subobject is proposed to be used as a
subobject of ERO. This subobject will be used in the ERO of the path
message used for establishing nested tunnels or splicing. The
description of the subobject is stated below.
3.1 LSP Subobject
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | LSPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route. If
the bit is not set, the subobject represents a strict hop in
the explicit route.
Type
TBD
Length
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 16.
Reserved
Zero on transmission. Ignored on receipt. This is used for
padding
IPv4 tunnel sender address
Vijayanand C October 2002 [page 3 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
IPv4 address for a sender node. This is the address of the outer
tunnel ingress.
IPv4 tunnel end point address
IPv4 address of the egress node for the tunnel.
Tunnel ID
A 16-bit identifier used in the SESSION of the tunnel that
remains constant over the life of the tunnel.
LSPID
A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC of the tunnel
The IPv4 tunnel sender address, IPv4 tunnel end point address,
Tunnel ID and LSPID are the parameters of the outer tunnel to be
used as a Hop by the inner tunnel.
4. Operational overview
When an LSP needs to be established with bandwidth reservation
the path is computed and an ERO is formed consisting of the hops
through which the LSP should pass so that the bandwidth constraints
can be satisfied. The path may contain an LSP with adequate
bandwidth to accommodate the bandwidth requirements of this LSP. In
this case, the new LSP can use the existing LSP as a single hop and
tunnel though it, provided the above LSP supports this. In the
forwarding plane, a label stack will exist inside the pre-
established LSP with the outer label being the label of the outer
tunnel LSP and the inner label being that of the inner tunnel LSP.
If the outer tunnel LSP is the last hop in the path of the new LSP
then the new LSP can be spliced onto the same provided the bandwidth
and policy considerations permit.
In order to signal this usage of an established LSP as a hop of
an LSP the ERO must carry the LSP subobject described previously.
This denotes that the LSP with the parameters described in the LSP
subobject will be used as a single hop for tunneling or splicing.
The LSP subobject containing information about the outer tunnel to
be used can be formed in the ingress of the inner tunnel or in the
Vijayanand C October 2002 [page 4 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
node which is the penultimate hop to the head of the outer tunnel.
Usually it is the administrator who has knowledge of the outer
tunnel to be used and hence the subobject would be inserted in the
ERO at the ingress itself.
The use of LSP subobject with the mechanism described in this
document is useful when the outer tunnel LSP is not an FA-LSP. This
approach therefore removes the necessity to use only FA-LSPs for
tunneling. In a network where only a few tunnels exist and knowledge
and bandwidth accounting of these tunnels is a simple administrative
task, the approach suggested is very useful.
Also, it could so happen that the outer tunnel LSP is part of
another signaling domain. In this case the above LSP may not be
advertised as an FA-LSP into other domains. Apart from this, policy
considerations of certain operators may prohibit them from
advertising the LSP as a link into the domain of another
operator/customer. In this case, when the outer tunnel is in another
signaling domain, apriori knowledge of the outer tunnel to be used
and its bandwidth should be known to the initiator of the inner
tunnel. This would be known by agreement with the operator in
that domain.
If the outer tunnel is part of the same domain but different or
same routing area as inner tunnel then this approach does not treat
the outer tunnel LSP as a single hop in the path computation for
inner tunnel. The hop list after path computation, may match with
that of the outer tunnel and hence the outer tunnel can be chosen as
a hop and tunneled through. Even if the outer tunnel information is
not present in the Traffic engineering database, the administrator
may have knowledge of the outer tunnel and use it, once he infers
that the outer tunnel hops match with those obtained and the
required bandwidth is supported in the outer tunnel.
The operation is described below with an example
_.....................
. .
R1------R2------r1=======r2========r3--------R3
. .
.....................
Vijayanand C October 2002 [page 5 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
An LSP is already established across the nodes r1,r2 and r3. Let
the < IPv4 tunnel sender address, IPv4 tunnel end point address,
Tunnel ID and LSPID > parameters of this LSP be <r1,r3,t1,L1> . If
another LSP needs to be established across R1,R2,r1,r2,r3,R3, which
uses the above tunnel, then ER Hop for the Path message would be [
R2, <r1,r3,t1,L1>,R3 ]. The four tuple <r1,r3,t1,L1> would be
carried in the LSP subobject proposed in this document. The node R2
when processing this ERO would recognize that the address r1 in the
LSP subobject as its next hop and propagate the LSP subobject to it.
The node r1 would process the LSP subobject and identify the tunnel
to be used from the four tuple described above. The LSP subobject
would be removed from the ERO by r1 and the Path message would be
then sent to r3 provided the bandwidth constraints of the LSP L1 are
not violated by admitting the new LSP. At r3, the node would
recognise that R3 is adjacent to it and propagate the path message
to it. Once the path message reaches R3 and the path state is
established the reserve message which traverses the same path back
to the ingress would establish the reservation state and the LSP
would be ready for data traffic. Let the new LSP be called L2. The
bandwidth remaining in the tunnel between r1 to r3 must be updated
with the bandwidth taken by establishing L2. When data is sent over
this new LSP - L2 a label stack would be carried between r1 and r3.
If the new LSP-L2 needs to be established across
R1,R2,r1,r2,r3 then the new LSP can be spliced/joined with the
existing LSP at r1. The path message would not be propagated beyond
r1 and there would be no label stack across r1,r2 and r3 when data
is carried.
5. Considerations for Path Computation
For the purpose of path computation the outer tunnel LSP is
transparent since it is not an FA-LSP. The administrator of the
inner tunnel shall use his knowledge of the outer tunnel to use it
as a hop in the ERO. Another scenario may arise when the outer LSP
is in a different domain. In this situation the topology of the
outer LSP domain may not be known outside the domain and hence the
path through that domain cannot be computed and matched against that
of the outer tunnel. In this situation, the owner of that domain
shall provide the LSP parameters to the user to tunnel across the
domain.
6. Interoperability Considerations
The nodes which do not recognize the LSP subobject should drop
the path message and send a path error with 'the Bad EXPLICIT_ROUTE
Vijayanand C October 2002 [page 6 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
object' described in RSVP-TE. In order to use the feature described
in this document the nodes which construct the subobject and process
it, namely the ingress of inner tunnel, ingress of outer tunnel and
penultimate hop must support the feature described in this document.
7. Open Issues
The knowledge of the outer tunnel LSP parameters must be known
the node which constructs the LSP subobject, namely the ingress of
inner tunnel LSP or penultimate hop of outer tunnel LSP.
8. Acknowledgements
The mechanism described in this document has been inspired by
literature about MPLS traffic engineering mechanisms. Specifically
the drafts authored by Kireeti Kompella, Yakov Rekhter, D. Awduche,
Chetan Kumar S have provided motivation to come up with this
contribution. The support given by other well-wishers and friends
during this work is recalled with gratitude.
9. Authors Address
Vijayanand C
HCL Technologies Limited
Technologies Division
PM Tower, 6th Floor,
37,Greams Road,
Chennai - 600 008, India
Phone : +91-44-8291735/36/37 Ext: 629
Email : vijayc@ctd.hcltech.com
10. References
[RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin
,"Resource ReSerVation Protocol (RSVP)",RFC2205 , September 1997
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan , G.
Swallow ," RSVP-TE: Extensions to RSVP for LSP Tunnels ",RFC
3209,December 2001.
[FA-LSP] Kireeti Kompella, Yakov Rekhter,"LSP Hierarchy with
Generalized MPLS TE",
[INTER-AREA-TE] Kireeti Kompella, Yakov Rekhter, Jean Philippe
Vasseur, Ting Wo Chung, "draft-kompella-mpls-multiarea-te-
03.txt",December 2002
Vijayanand C October 2002 [page 7 ]
INTERNET DRAFT LSP Subobject for RSVP-TE March 2003
[LSP-OSPF] Chetan Kumar S, Sunil Kumar," Signalling LSPID's in OSPF
TE ",draft-chetan-lspid-ospf-00.txt, March 2002.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
draft-katz-yeung-ospf-traffic-05.txt,June 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-traffic-03.txt, June 2001.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.
Vijayanand C October 2002 [page 8 ]