Network Working Group Naiming Shen
Internet Draft Enke Chen
Albert Tian
Expiration Date: January 2005 Redback Networks
Discovering LDP Next-Nexthop Labels
<draft-shen-mpls-ldp-nnhop-label-01.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 specifies extensions to LDP in support of next-nexthop
label discovery. The next-nexthop label information can be used to
fast re-route LDP LSP traffic into an explicitly routed tunnel
for nexthop node protection in the case of a link or node failure.
Conventions used in this document
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 [5].
Shen, Chen, Tian Expires January 2005 [Page 1]
Internet Draft LDP Next-Nexthop Label July 2004
1. Introduction
As currently specified in [1], the LDP protocol only needs to know
label mapping for the adjacent peers and there is no way for an LSR
to learn the adjacent peer's downstream label mapping. This document
proposes an LDP extension that allows an LSR to discover the
next-nexthop label mapping from its downstream peers.
One application for learning the next-nexthop label mapping is
for fast re-route. Similar to the facility based node-protection
of LSP Fast ReRoute [2], the NFRR (Nexthop Fast ReRoute) [3] scheme
allows an LSR to perform Fast ReRoute on any type of traffic,
including LDP LSP traffic. When the Nexthop Fast ReRoute is used
for node-protection of LDP LSP traffic, the next-nexthop labels are
needed to tunnel the data traffic into the next-nexthop LSR in the
case of a link or node failure.
A new Status TLV code is specified for an LSR to indicate its
interest in receiving the next-nexthop label mapping information.
A new Next-Nexthop Label TLV is specified to pass the downstream
label mapping to the upstream LSR in the Label Mapping Message.
The extension specified in this document assumes the next-nexthop
nodes use platform-wide label space for LDP. It is outside the
scope of this document when the next-nexthop nodes use
per-interface label space.
2. LDP Next-Nexthop Label Mapping Scheme
2.1 Example
Confiser LSRs interconnected with LDP as the following:
+----------+
| lsp2 | (link-protection)
| V
| ||=>c[R3]
| ||
[R1]====>[R2]a=|| X
| || /
| ||===>b[R4]====>[R5]
| (x2) (x1) ^
| |
| (z1) (z2) |
+-------[R6]-----------+
lsp1 (node-protection)
Figure 1: NFRR node-protection for LDP data traffic
R2 is the PLR (Point of Local Repair) node, the lsp1 is the
Shen, Chen, Tian Expires January 2005 [Page 2]
Internet Draft LDP Next-Nexthop Label July 2004
NFRR [3] LSP for the purpose of protecting node R4 over R2's
interface "a". The lsp2 is the NFRR LSP for link protection in
the case of interface "a" or "c" is down. We will only be
concerned with node-protection using lsp1 in this document.
R5 advertises FEC X to R4 with label x1. R4 advertises the same
FECs with label x2 to upstream peer R2. The RSVP signaled lsp1
uses label z1 from R2 to R6 and z2 from R6 to R5, and z2 can
also be an implicit null.
When R2 detects either the interface "a" is down, or the nexthop
"b" is unreachable, or LSR R4 is down, the forwarding engine on
R2 will re-direct the LDP data traffic into the NFRR tunnel lsp1.
This can be quickly done by pushing the label x1 onto the label
stack and send the packet through the lsp1 for LDP data traffic
going to FEC X. As long as the platform-wide label space is
used on LSR R5, the R5 does not even know the difference. In
this case, the next-nexthop label x1 is used by PLR node R2
for fast re-route with node-protection. For this scheme to work,
LSR R4 needs to advertise the next-nexthop label x1 to the
upstream LSR R2 in addition to their own label mapping of x2 for
the same FEC.
2.2 Next-Nexthop Label Request
Take the same example as in section 2.1, a user can statically
configure on LSR R4 that it needs to include downstream labels
to all or some of the upstream peers while it advertises the
label mappings. A better way is for LSR R2 to make a request
to its peer R4 that it is interested in receiving the next-nexthop
label mapping information, since R2 has already been configured
to perform node-protection for LSR R4.
When the LDP peer between R2 and R4 is up, and there is at least
one NFRR lsp configured on R2 to perform node-protection of R4,
R2 can optionally send a Notification Message with the Next-Nexthop
Label Request bit set in the Status TLV. When the last NFRR LSP
protecting node R4 is removed, R2 can optionally send the
Notification Message to R4 with the Next-Nexthop Label Withdraw bit
set in the Status TLV.
2.3 Next-Nexthop Label Advertisement
When an LSR advertises the FEC-label bindings to its peer, if it
has received the Next-Nexthop Label Request from that peer or the
LSR is configured with this capability, it SHOULD include the
next-nexthop label mapping information when applicable in the
Label Mapping Message.
An optional Next-Nexthop Label TLV is defined to be used in the
Label Mapping Message. The Next-Nexthop Label contains a list
Shen, Chen, Tian Expires January 2005 [Page 3]
Internet Draft LDP Next-Nexthop Label July 2004
of (label, downstream router-id) tuples. More than one tuple
can be used when there is an ECMP case to different downstream
nodes for the same FECs. It is an implementation and local
configuration issue whether to announce only one or multiple
tuples in the ECMP case.
If some FECs are not advertised with next-nexthop labels, then
no node-protection can be performed on those FECs. But they
can still be fast re-routed with NFRR link-protection scheme [3].
If there is a NFRR LSP built from R2 to R4, then the LDP data
traffic will be re-routed directly onto R4 itself. The
node-protection is not meant for all the situations. Usually
node-protection is used in the backbone portion of the network,
and link-protection is used close to the edge of the network.
2.4 Next-Nexthop Label Update
If an LSR advertises the Next-Nexthop Label TLV in the Label
Mapping Messages, and when the next-nexthop label information
changes, it MUST re-send the Label Mapping Message with updated
next-nexthop label information. The LSR SHOULD implement a means
to dampen the re-advertisement to avoid potentially excessive
updating due to link flapping.
3. Next-Nexthop Label Packet Encoding
3.1 Next-Nexthop Label Bits in Status TLV
The Next-Nexthop Label Request/Withdraw information is sent in the
Notification Message. Two bits (to be allocated by IANA) are
defined in this document, one for Request and one for Withdraw.
Unlike most of the bits already defined in the Status TLV,
the Next-Nexthop Label Bits are used by an LSR to dynamically
announce a capability to its peers.
The E bit and F bit MUST be set to zero if Next-Nexthop Label
Request or Withdraw is the only status code set. The Next-Nexthop
Label Bits SHOULD only be used in Notification Message, otherwise
it MUST be quietly ignored upon receipt.
3.2 Next-Nexthop Label TLV in Label Mapping Message
The Next-Nexthop Label TLV can be optionally carried in the Optional
Parameters field of a Label Mapping Message. The TLV consists a
list of (label, router-id) pairs with the following format:
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| Next-Nexthop Label (IANA) | Length (4 + N * 8 bytes) |
Shen, Chen, Tian Expires January 2005 [Page 4]
Internet Draft LDP Next-Nexthop Label July 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NNhop-Label 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NNhop Router-ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NNhop-Label N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NNhop Router-ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NNhop-Label
Next-Nexthop Label. This is a 20-bit label value as specified
in [4] represented as a 20-bit number in a 4 octet field.
NNhop Router-ID
Next-Nexthop router-ID which advertised that next-nexthop label.
This is a 4 octet number.
4. Security Considerations
This mechanism does not introduce any new security issue in LDP.
5. IANA Considerations
Two new bits in Status TLV and a new LDP TLV Type is defined in
section 3. This LDP extension requires that IANA allocate those
numbers.
6. Acknowledgments
TBD.
7. References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[2] Pan, P., Gan, D., Swallow, G., Vasseur, J.Ph., Copper, D.,
Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE",
Internet draft, draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt,
work in progress.
Shen, Chen, Tian Expires January 2005 [Page 5]
Internet Draft LDP Next-Nexthop Label July 2004
[3] Shen, N., Pan, P., "Nexthop Fast ReRoute for IP and MPLS",
Internet draft, draft-shen-nhop-fastreroute-01.txt, work in
progress.
[4] Rosen, E., Tappan, D., Federkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8. Authors' Addresses
Naiming Shen
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
e-mail: naiming@redback.com
Enke Chen
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
e-mail: enke@redback.com
Albert Tian
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
e-mail: tian@redback.com
IPR Notice
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
Shen, Chen, Tian Expires January 2005 [Page 6]
Internet Draft LDP Next-Nexthop Label July 2004
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shen, Chen, Tian Expires January 2005 [Page 7]