Internet DRAFT - draft-chen-mpls-ldpigp-syn-accurate
draft-chen-mpls-ldpigp-syn-accurate
Network Working Group Emily. Chen
Internet Draft Huawei Technologies Co., Ltd.
Expires: October 2007 June 2007
Explicit Notification for LDP-IGP Synchronization
draft-chen-mpls-ldpigp-syn-accurate-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Trust (2007).
Abstract
A fundamental concept in Label Distribution Protocol - Interior
Gateway Protocol (LDP-IGP) Synchronization is that LDP is fully
established before the IGP path is switched for IP forwarding. This
document proposes a mechanism to affirm the switching time accurately
Emily Expires October 2007 [Page 1]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
by propagating a explicit notification from downstream. The
interoperability with other Label Switched Routers (LSRs), which may
not support the mechanism, is also considered.
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 [i].
Table of Contents
1. Introduction.................................................2
1.1. Background..............................................2
1.2. Problem Statement.......................................3
1.3. Overview of Proposed Solution...........................4
2. Operation of Explicit Notification...........................4
2.1. Procedure for the Sender of Explicit Notification.......4
2.2. Procedure for the Receiver of Explicit Notification.....5
3. Specification of Proposed Solution...........................5
3.1. Introduction............................................5
3.2. Determine Whether LDP is Fully Established..............6
3.3. Solution 1: Extension to Notification Message...........6
3.4. Solution 2: Extension to Label Mapping Message..........7
4. Interoperability.............................................8
5. Security Considerations......................................8
6. IANA Considerations..........................................8
7. Acknowledgments..............................................8
8. References...................................................9
8.1. Normative References....................................9
8.2. Informative References..................................9
Author's Addresses.............................................10
Intellectual Property Statement................................10
Disclaimer of Validity.........................................10
Copyright Statement............................................11
1. Introduction
1.1. Background
Label Distribution Protocol (LDP) [RFC 3036] defines a set of
procedures and messages by which Label Switched Routers (LSRs)
establish Label Switched Paths (LSPs) through a network by mapping
Emily Expires October 2007 [Page 2]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
network-layer routing information directly to data-link layer
switched path. In Downstream Unsolicited advertisement mode, label
mapping advertisements for all routers may be received from all LDP
peers. When using liberal label retention, every label mappings
received from a peer LSR is retained regardless of whether the LSR is
the next hop for the advertised mapping.
If two LSRs rely on the availability of a complete MPLS forwarding
path to each other, such as in a L2VPN or L3VPN scenario, along the
IP shortest path from one PE router to the other, all the links need
to have operational LDP sessions and the necessary label binding
must have been exchanged over those sessions. LDP-IGP synchronization
should be used to make sure that LDP is fully operational before the
IGP path is switched for IP forwarding . When LSPs are not all ready
on a certain link, IGP will advertise the link with maximum cost to
prevent any traffic transmission over it. In this case, LDP will
setup session and advertise label mapping message to all LDP peers
for all routes over the certain link. After LDP session is
established and labels are exchanged, all the liberal LSPs will be
setup, then IGP will re-advertise the link, and MPLS forwarding will
be implemented over it.
1.2. Problem Statement
In a MPLS L2VPN or L3VPN scenario, all the VPN traffic is forwarded
through the LDP LSPs in public network. In this case, MPLS forwarding
in public network should not be interrupted; otherwise all the VPN
traffic would be interrupted too, which would lead to serious
telecommunication problem. Thus, for the sake of maintaining MPLS
forwarding capability, IGP path must not be used for IP forwarding
before LDP is fully operational and all LSPs are created. In the
normal solution of LDP-IGP synchronization, this can be implemented
by IGP to delay some specified time to inform LDP about route change.
But the delayed time is not sure, that may still result that LDP-IGP
is not synchronized on time and mpls forwarding is interrupted, such
as, the time to exchange label binding for two many LSPs is longer
than the delayed time. Even if the delayed time is enough, it can
not be expected to switch MPLS forwarding to the preferable path and
avoid long occupation on not best path.
Thus the switching time for LDP-IGP synchronization should be
affirmed accurately to prevent any traffic from being discarded, and
avoid the important traffic from being forwarded through a non-
optimal path in long time even if the optimal path is operational.
Emily Expires October 2007 [Page 3]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
1.3. Overview of Proposed Solution
This document aims to propose a mechanism to affirm the switching
time accurately. When all the labels are exchanged, the downstream
LSR will propagate a explicit notification to upstream, which
indicates that LDP is ready for mpls forwarding. Note that this
explicit notification can be extension to some messages defined in
LDP Specification [RFC 3036], such as label mapping message,
notification message, etc. To interact with other LSRs which may not
support the mechanism, the behavior of sending explicit notification
MUST be restricted by configuration.
2. Operation of Explicit Notification
When LDP is fully established and all LSPs are exchanged, a explicit
notification will be propagated from downstream LSR to upstream.
This section defines the operation of explicit notification in the
following case:
- Sender/receiver of explicit notification ;
- Capability of sending/responding explicit notification .
2.1. Procedure for the Sender of Explicit Notification
After LDP session is established and labels are all exchanged, a
downstream LSR should check whether it has the capability of sending
explicit notification , which is restricted by configuration.
If a downstream LSR is configured the capability of sending explicit
notification, it is responsible to determine whether LDP is fully
established. The method of validation here depends on the category of
explicit notification . Once the LSR confirms that all the labels are
exchanged, it will construct a explicit notification and send to the
upstream LSR actively.
If a downstream LSR is NOT configured the capability of sending
explicit notification , it does not need to determine whether LDP is
fully established, nor send a explicit notification . In this case,
it can be considered as a normal LSR, which only complies with the
fundamental of LDP.
Emily Expires October 2007 [Page 4]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
2.2. Procedure for the Receiver of Explicit Notification
An upstream LSR will receive the explicit notification passively,
without reference to the capability of proposed mechanism. But the
procedure of dealing with the explicit notification depends on its
capability of response, which is restricted by configuration. The
configuration ability is recommend but not required.
If an upstream LSR is configured the capability of responding
explicit notification, it is responsible to switch IGP path
immediately when it receives the message. To avoid the influence of
missing explicit notification, maintaining a hold timer with each IGP
path is recommended. The hold timer, which expires in a configured
time, should be created at the beginning of LDP establishment. If a
explicit notification is received, the hold timer should be deleted
after responding the message successfully. If the timer expires
without receipt of a explicit notification, the upstream LSR will
also switch the IGP path. Note that a upstream LSR can not respond
explicit notification any more after the hold timer expires,
otherwise IGP path will be switched twice, which is not reasonable.
If an upstream LSR is NOT configured the capability of responding
explicit notification, it does not need to switch IGP path when
receiving a explicit notification. To prevent MPLS forwarding from
being interrupted for too long, maintaining a hold timer with each
IGP path is recommend. The hold timer, which expires in a configured
time, should be created at the beginning of LDP establishment. IGP
path will be switched when the hold timer expires. The disadvantage
of maintaining a hold timer without responding explicit notification
is that, the interval of hold timer is difficult to determine, and
the switching time of IGP path can not be affirmed accurately.
3. Specification of Proposed Solution
As described in previous sections, a explicit notification can be
extension to some messages, such as label mapping message,
notification message, etc. This document specifies the solution with
extending notification message , and another alternative solution
with label mapping message, the above both message are defined in
LDP Specification [RFC 3036].
3.1. Introduction
When establishing LSPs, an LSR will send a label mapping message to
an LDP peer to advertise FEC-label bindings. After all the labels are
Emily Expires October 2007 [Page 5]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
exchanged, the LSR will send a special explicit notification, which
can prompt the LDP peer to switch IGP path.
3.2. Determine Whether LDP is Fully Established
As the sender of explicit notification, it is responsible to
determine whether LDP is fully established. The proposed solution
defines two methods for validation:
- All FECs have been advertised;
- Maintain a Check Timer for Sending Label Mapping Messages.
When establishing LSPs, an LSR will send label mapping messages
according to the FECs. If the last of FECs has been advertised, it is
reasonable to consider that all the FEC elements have been advertised
and LDP is fully operational.
If there is any FEC to be advertised, an LSR will send label mapping
messages continuously. Once the LSR maintains a check timer, which
expires in a configured time, it will restart the timer when sending
a label mapping message. In this case, expiration of the check timer
indicates that the LSR has not sent a label mapping message in a
certain while. Thus it is reasonable to consider that all the FECs
have been advertised when the check timer expires.
3.3. Solution 1: Extension to Notification Message
LDP Specification [RFC 3036] prescribes that an LSR sends a
Notification message to inform an LDP peer of a significant event. To
inform the event that LDP is fully established, the Notification
Message can be adopted as the explicit notification with the Status
TLV defined as follows:
The encoding for the Status TLV is:
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|1| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
Emily Expires October 2007 [Page 6]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following are the Status Code defined:
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|1| Status Data (Fully Established) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Data: the 30-bit unsigned integer specifies the status that
LDP is fully established for the explicit notification , this code
point is required to be assigned by IANA.
3.4. Solution 2: Extension to Label Mapping Message
As the sender of explicit notification , it is responsible to
construct the message. The proposed solution defines the method to
extend label mapping message, which does not go against LDP
Specification [RFC 3036]:
LDP Specification [RFC 3036] prescribes that FEC TLV is indispensable
for a label mapping message. The FEC element encoded in the label
mapping message is corresponding with the FEC to be advertised. For
the reason of that the special label mapping message is not used to
advertise any FEC, it does not have any FEC to correspond with.
Therefore, if the receiver of the special label mapping message
recognizes that FEC element is cleared, it can distinguish this
message from the normal messages.
The encoding for the special label mapping message is:
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| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
Emily Expires October 2007 [Page 7]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the elements are the same as LDP Specification [RFC 3036],
except that FEC TLV is encoded as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FEC (0x0100) | Length (0x0020) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Interoperability
To interoperate with other LSRs which do not support this mechanism,
an LSR supporting this mechanism should not be configured the
capability of sending a explicit notification. In this case, all the
routers will act as normal LSRs, complying with the fundamentals. The
configuration can prevent the communication system from any error
brought by the explicit notification.
5. Security Considerations
Once LDP service is destroyed over a link, the proposed mechanism
will not take any effect. But in working order, this mechanism does
not introduce any new weaknesses in LDP nor IGP. In fact, it is
beneficial to prevent MPLS traffic from being interrupted. It can be
considered as an informational extension of LDP Specification [RFC
3036] and LDP-IGP Synchronization.
6. IANA Considerations
This document specifies the following which require code points
assigned by IANA:
- LDP Status Code code point for the status that LDP is fully
established. The authors request Status Code 0x00000031.
7. Acknowledgments
Thanks to Ru Liang and Mach Chen for technical contributions.
Emily Expires October 2007 [Page 8]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
8. References
8.1. Normative References
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture",
RFC 3031, Cisco Systems, Inc., Force10 Networks, Inc.,
Juniper Networks, Inc., January 2001.
[RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas,
" LDP Specification", RFC 3036, Nortel Networks Inc.,
Ennovate Networks, IBM Corp, PhotonEx Corp, Cisco Systems,
Inc., January 2001.
8.2. Informative References
[1] M. Jork, A. Atlas, L. Fang, "LDP IGP Synchronization", Reef
Point, Google, AT&T, June 2006.
[RFC3906] N. Shen, H. Smit, P., " Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, Redback Networks, October 2004.
Emily Expires October 2007 [Page 9]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
Author's Addresses
Emily Chen
Huawei Technologies Co., Ltd.
NO.5 Streat, Shangdi Information
Haidian
Beijing
China
Phone: 86-010-8283-6980
Email: chenying220@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Emily Expires October 2007 [Page 10]
Internet-Draft Explicit Notification for LDP-IGP SYN June 2007
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
