Network Working Group Kamran Raza
Internet Draft Sami Boutros
Updates: 5036, 4447 (if approved) Luca Martini
Intended status: Standards Track
Expires: December 31, 2011 Cisco Systems, Inc.
July 1, 2011
Applicability of LDP Label Advertisement Mode
draft-raza-mpls-ldp-applicability-label-adv-00.txt
Abstract
An LDP speaker negotiates the label advertisement mode with its LDP
peer at the time of session establishment. Although different
applications sharing the same LDP session may need different modes
of label distribution and advertisement, there is only one type of
label advertisement mode that is negotiated and used per LDP
session. This document clarifies the use and the applicability of
session's negotiated label advertisement mode, and categorizes LDP
applications into two broad categories of negotiated mode-bound and
mode-independent applications. This document proposal and
clarification thus updates [RFC5036] and [RFC4447].
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), 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
This Internet-Draft will expire on December 31, 2011.
Raza, et. al Expires December 2011 [Page 1]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
Copyright Notice
Copyright (c) 2011 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 3
2. Conventions used in this document 3
3. Label Advertisement Mode Applicability 4
3.1. Label Advertisement Mode Negotiation 4
3.2. LDP Applications Categorization 4
3.2.1. Session mode-bound Applications 5
3.2.2. Session mode-independent Applications 5
3.3. Update to RFC-5036 6
3.4. Update to RFC-4447 6
4. Future Work 6
5. Security Considerations 6
6. IANA Considerations 7
7. References 7
7.1. Normative References 7
7.2. Informative References 7
8. Acknowledgments 7
Raza, et. al Expires December 2011 [Page 2]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
1. Introduction
The MPLS architecture [RFC3031] defines two modes of label
advertisement for an LSR:
1. Downstream-on-Demand
2. Unsolicited Downstream
The "Downstream-on-Demand" mode requires an LSR to explicitly
request the label binding for FECs from its peer, whereas
"Unsolicited Downstream" mode allows an LSR to distribute the label
binding for FECs unsolicitedly to LSR peers that have not explicitly
requested them. The MPLS architecture [RFC3031] also specifies that
on any given label distribution adjacency, the upstream LSR and the
downstream LSR must agree to using a single label advertisement
mode.
Label Distribution Protocol (LDP) [RFC5036] allows label
advertisement mode negotiation at the session establishment time
(section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP
specification also dictates that only one label advertisement mode
is agreed and used on a given LDP session between two LSRs.
With the advent of new applications, such as L2VPN [RFC4447], mLDP
[MLDP], ICCP [ICCP], running on top of LDP, there are situations
when an LDP session is shared across more than one application to
exchange label bindings for different type of FECs. Although
different applications sharing the same LDP session may need
different type of label advertisement mode negotiated, there is only
one type of label advertisement mode that is negotiated and agreed
at the time of establishment of LDP session.
This document clarifies the use and the applicability of session's
label advertisement mode for each application using the session. It
also categorizes LDP applications into two broad categories of
negotiated mode-bound and mode-independent applications. This
document proposal and clarification thus updates [RFC5036] and
[RFC4447].
2. 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 [RFC2119].
Raza, et. al Expires December 2011 [Page 3]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
The unqualified term "mode" used in document refers to "label
advertisement mode".
Please also note that LDP specification [RFC5036] uses the term
"Downstream Unsolicited" to refer to "Unsolicited Downstream", as
well as uses the terms "label distribution" and "label
advertisement" interchangeably. This document also uses these
terms interchangeably.
3. Label Advertisement Mode Applicability
3.1. Label Advertisement Mode Negotiation
Label advertisement mode is negotiated between participating LSR
peers at the time of session establishment. The label advertisement
mode is specified in LDP Initialization message's "Common Session
Parameter" TLV by setting A-bit (Label Advertisement Discipline bit)
to 1 or 0 for Downstream-on-Demand or Downstream-Unsolicited modes
respectively [RFC5036]. The negotiation of the A-bit is specified in
section 3.5.3 of [RFC5036] as follows:
"If one LSR proposes Downstream Unsolicited and the other proposes
Downstream on Demand, the rules for resolving this difference is:
- If the session is for a label-controlled ATM link or a label-
controlled Frame Relay link, then Downstream on Demand MUST be
used.
- Otherwise, Downstream Unsolicited MUST be used."
Once label advertisement mode has been negotiated and agreed, both
LSRs must use the same mode for label binding exchange.
3.2. LDP Applications Categorization
At the time of standardization of LDP base specification RFC-3036,
the earlier applications using LDP to exchange their FEC bindings
were:
. Dynamic Label Switching for IP Prefixes
. Label-controlled ATM/FR
Since then, several new applications have emerged that use LDP to
signal their FEC bindings and/or application data:
. L2VPN P2P PW ([RFC4447])
Raza, et. al Expires December 2011 [Page 4]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
. L2VPN P2MP PW ([P2MP-PW])
. mLDP ([MLDP])
. ICCP ([ICCP])
We divide these LDP applications into two broad categories from
label advertisement mode usage point of view:
1. Session mode-bound Applications (i.e. use the negotiated label
advertisement mode)
2. Session mode-independent Applications (i.e. do not care about the
negotiated label advertisement mode)
3.2.1. Session mode-bound Applications
The FEC label binding exchange for such LDP applications MUST use the
negotiated label advertisement mode.
The early LDP applications "Dynamic Label Switching for IP Prefixes"
and "Label-controlled ATM/FR" fall into this category.
3.2.2. Session mode-independent Applications
The FEC label binding, or any other application data, exchange for
such LDP applications does not care about, nor tied to the
negotiated label advertisement mode of the session; rather, the
information exchange is driven by the application need and
procedures as described by their respective specifications. For
example, [MLDP] specifies procedures to advertise P2MP FEC label
binding in an unsolicited manner, irrespective of the negotiated
label advertisement mode of the session.
The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this
category of LDP application.
3.2.2.1. Upstream Label Assignment
As opposed to downstream assigned label advertisement defined by
[RFC3031], [LDP-UPSTREAM] specification defines new mode of label
advertisement where label advertisement and distribution occurs for
upstream assigned labels.
As stated in earlier section 3.1 of this document, [RFC5036] only
allows specifying Downstream-Unsolicited or Downstream-on-Demand
mode. This means that any LDP application that requires upstream
Raza, et. al Expires December 2011 [Page 5]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
assigned label advertisement also falls under the category of Session
mode-independent application.
3.3. Update to RFC-5036
For clarification reasons, section 3.5.3 of [RFC5036] is updated to
add following two statements under the description of "A, Label
Advertisement Discipline":
- The negotiated label advertisement discipline only applies to FEC
label binding advertisement of "Address Prefix" FECs;
- Any document specifying a new FEC SHOULD state the applicability
of the negotiated label advertisement discipline for that FEC.
3.4. Update to RFC-4447
[RFC4447] specifies LDP extensions and procedures to exchange label
bindings for P2P PW FECs. The section 3 of [RFC4447] states:
"LDP MUST be used in its downstream unsolicited mode."
Since PW application falls under session mode-independent
application category, the above statement in [RFC4447] should be
read to mean as follows:
"LDP MUST exchange PW FEC label bindings in downstream unsolicited
manner, independent of the negotiated label advertisement mode of
the LDP session."
4. Future Work
This document only clarifies the existing behavior for LDP label
advertisement mode for different applications without defining any
protocol extensions. In future, a new LDP capability [RFC5561] based
mechanism can be defined to signal/negotiate label advertisement
mode per FEC/application.
5. Security Considerations
This document specification only clarifies the applicability of LDP
session's label advertisement mode, and hence does not add any LDP
security mechanics and considerations to those already defined in
LDP specification [RFC5036].
Raza, et. al Expires December 2011 [Page 6]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
6. IANA Considerations
None.
7. References
7.1. Normative References
[RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
Specification", RFC 5036, September 2007.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
7.2. Informative References
[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G.
Heron, "Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006.
[P2MP-PW] Boutros, S., Martini, L., Sivabalan, S., Del Vecchio, G.,
Kamite, Jin, L., "Signaling Root-Initiated P2MP PWs using
LDP", draft-ietf-pwe3-p2mp-pw-02.txt, Work in Progress,
March 2011.
[MLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B.,
"LDP Extensions for Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp
-14.txt, Work in Progress, June 2011.
[ICCP] Martini, L., Salam, S., Sajassi, A., and Matsushima, S.,
"Inter-Chassis Communication Protocol for L2VPN PE
Redundancy", draft-ietf-pwe3-iccp-05.txt, Work in
Progress, April 2011.
[UPSTREAM-LDP] Aggarwal, R., and Le Roux, J.L., "MPLS Upstream Label
Assignment for LDP", draft-ietf-mpls-ldp-upstream-10.txt,
Work in Progress, February 2011.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le
Roux, JL., "LDP Capabilities", RFC 5561, July 2009.
8. Acknowledgments
The authors would like to acknowledge Eric Rosen and Rajiv Asati for
their review and input.
Raza, et. al Expires December 2011 [Page 7]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2011
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive,
Kanata, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way,
San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400,
Englewood, CO 80112, USA.
E-mail: lmartini@cisco.com
Raza, et. al Expires December 2011 [Page 8]