Internet DRAFT - draft-li-mpls-label-stack-distribution
draft-li-mpls-label-stack-distribution
Network Working Group Z. Li
Internet-Draft L. Zheng
Intended status: Standards Track Huawei Technologies
Expires: April 24, 2014 October 21, 2013
LDP and RSVP-TE Extensions for Label Stack Distribution
draft-li-mpls-label-stack-distribution-00
Abstract
This document defines the necessary extension for LDP and RSVP-TE to
distribute more than one label (label stack) for specific FEC between
label distribution peers.
Requirements Language
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2014.
Copyright 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
Li & Zheng Expires April 24, 2014 [Page 1]
Internet-Draft LDP & RSVP-TE Label Stack October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Label Stack/FEC Binding . . . . . . . . . . . . . . . . . . . 2
3. LDP Label Stack TLV . . . . . . . . . . . . . . . . . . . . . 3
4. RSVP-TE Label Stack Object . . . . . . . . . . . . . . . . . 4
5. Data Plane Processing of Label Stack . . . . . . . . . . . . 4
5.1. Upstream LSR . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Downstream LSR . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The MPLS architecture [RFC3031] defines a label distribution protocol
is a set of procedures by which one LSR informs another of the label/
FEC bindings it has made. LDP [RFC5036] and RSVP-TE [RFC3209] are
two protocols defined for distributing labels. For specific FEC,
both LDP and RSVP-TE distribute only one label. As the application
based on MPLS develops, there proposes requirements to allocate more
than one label for a specific FEC. This document discusses the
possible usage of allocation of more than one label and defines the
corresponding protocol extensions of LDP and RSVP-TE
2. Label Stack/FEC Binding
[RFC3107] defines how BGP is used to distribute MPLS label binding
when BGP is used to distribute a particular route. Label mapping
information is carried as part of the Network Layer Reachability
Information (NLRI) in the Multiprotocol Extensions attributes.
Unlike the one label/FEC binding for LDP and RSVP-TE, one or more
labels could be carried in the NLRI. The label stack allocating for
a specific FEC can be useful in the following situations:
- Other than the tunnel label, the extra label in the label stack
could be used for load balancing on the downstream LSR
- the extra label in the label stack could be used for QoS on the
downstream LSR
Li & Zheng Expires April 24, 2014 [Page 2]
Internet-Draft LDP & RSVP-TE Label Stack October 2013
- the multiple labels can be combined to form a big label or be used
as the context label for forwarding
In addition, the labels in the allocated label stack can be only
explained by the downstream LSR's own. That is, the upstream LSR
does not need to be aware of the meaning of each label in the label
stack. This can achieve great extensibility.
3. LDP Label Stack TLV
[RFC5036] defines several different kinds of Label TLVs. This
document defines a new type of LDP Label TLV, the LDP Label Stack
TLV. The LDP Label Stack TLV, same as other types of Label TLVs, is
carried by the messages used to advertise, request, release, and
withdraw label mappings. The encoding of the LDP Label Stack TLV is
as follows. The Label Stack TLV type is to be allocated by IANA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label Stack (TBA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label n (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. LDP Label Stack TLV
Each label is represented as a 20-bit number in a 4 octet field as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li & Zheng Expires April 24, 2014 [Page 3]
Internet-Draft LDP & RSVP-TE Label Stack October 2013
4. RSVP-TE Label Stack Object
This documents defines a new RSVP-TE object, the RSVP-TE Label Stack
Object. Label Stack Object MAY be carried in Resv messages.
Different from the Label Object defined in [RFC3209], the contents of
a Label Stack Object is multiple labels, encoded in 4 octets
respectively. The encoding of the RSVP-TE Label Stack Object
including the common object header is as follows, the C_Type is to be
allocated by IANA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type(TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label n (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. RSVP-TE Label Stack Object
5. Data Plane Processing of Label Stack
This section defines data plane processing of Label Stack on upstream
and downstream LSR.
5.1. Upstream LSR
Suppose upstream LSR is capable of processing label stack/FEC
binding. Suppose upstream LSR and Downstream LSR have agreed to bind
Label Stack LS to FEC F, for packets sent from upstream LSR to
Downstream LSR. Before a packet is sent from upstream LSR to
Downstream LSR, the whole Label Stack LS SHOULD be pushed on to the
packet.
5.2. Downstream LSR
Li & Zheng Expires April 24, 2014 [Page 4]
Internet-Draft LDP & RSVP-TE Label Stack October 2013
When the labeled packet arrives at the downstream LSR, the whole
Label Stack LS SHOULD be processed by the downstream LSR. The Label
Stack LS will be either popped out or replaced by new label or Label
Stack. How the Label Stack LS is used on downstream LSR can be a
local manner. But the label in the Label Stack LS MUST NOT leak to
the downstream LSR by this downstream LSR. That is, partial
decapsulation of the Label Stack are not permitted.
6. IANA Considerations
The IANA is requested to assign a new TLV from the "TLV Type Name
Space " registry.
Value Meaning Reference
----- ------------------- ---------
TBA LDP Label Stack TLV this document (sect 4)
The IANA is requested to assign a new C-Type from the "Class Type "
registry.
Value Meaning Reference
----- ------------------ ---------
TBA RSVP-TE Label Stack this document (sect 5)
7. Security Considerations
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[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.
Li & Zheng Expires April 24, 2014 [Page 5]
Internet-Draft LDP & RSVP-TE Label Stack October 2013
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
8.2. Informative References
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Lianshu Zheng
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: vero.zheng@huawei.com
Li & Zheng Expires April 24, 2014 [Page 6]
