Internet DRAFT - draft-raza-mpls-ldp-applicability-label-adv
draft-raza-mpls-ldp-applicability-label-adv
MPLS Working Group Kamran Raza
Internet Draft Sami Boutros
Updates: 5036, 4447 (if approved) Luca Martini
Intended status: Standards Track Cisco Systems, Inc.
Expires: January 15, 2013
Nicolai Leymann
Deutsche Telekom
July 16, 2012
Applicability of LDP Label Advertisement Mode
draft-raza-mpls-ldp-applicability-label-adv-03.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. The document also suggests an update
to RFC 5036 and RFC 4447 to remove any ambiquity and conflict in the
area of using correct label advertisement mode for a given
application.
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
Raza, et. al Expires January 2013 [Page 1]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 12, 2012.
Copyright Notice
Copyright (c) 2012 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. Mode-based Categorization of LDP Applications 4
3.2.1. Session mode-bound Applications 5
3.2.2. Session mode-independent Applications 5
3.3. Unacceptable label advertisement mode 6
4. Clarification on Mode Applicability 6
4.1. Update to RFC-5036 7
4.2. Update to RFC-4447 7
5. Security Considerations 7
6. IANA Considerations 7
7. References 7
7.1. Normative References 7
7.2. Informative References 8
8. Acknowledgments 8
Raza, et. al Expires January 2013 [Page 2]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
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 to LSR peers that have not explicitly requested
them. The MPLS architecture also specifies that on any given label
distribution adjacency, the upstream LSR and the downstream LSR must
agree to use a single label advertisement mode.
Label Distribution Protocol (LDP) [RFC5036] allows label
advertisement mode negotiation at time of session establishment
(section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP
specification also dictates that only single label advertisement
mode is agreed and used for a given LDP session between two LSRs.
With the advent of new LDP applications, such as L2VPN [RFC4447],
mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP
session is shared across more than one application to exchange label
bindings for different types of FEC. Although different applications
sharing the same LDP session may need a 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 label
advertisement mode of a session for each application using the
session. It also categorizes LDP applications into two broad
categories of mode-bound and mode-independent applications.
The document also suggests an update to RFC-5036 and RFC-4447 to
remove any ambiguity and conflict in the area of using correct label
advertisement mode for a given LDP application.
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 January 2013 [Page 3]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
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". The
LDP specification also uses the terms "label distribution mode" and
"label advertisement mode" interchangeably. Like LDP specification
document, this document also uses these terms interchangeably.
3. Label Advertisement Mode Applicability
3.1. Label Advertisement Mode Negotiation
Label advertisement mode is negotiated between 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.
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
LSR peers must use the same mode for label binding exchange.
3.2. Mode-based Categorization of LDP Applications
The earlier applications, defined and identified at the time of
standardization of LDP base specification RFC-3036, 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. These include:
. L2VPN P2P PW ([RFC4447])
Raza, et. al Expires January 2013 [Page 4]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
. L2VPN P2MP PW ([P2MP-PW])
. mLDP ([RFC6388])
. ICCP ([ICCP])
We divide the LDP applications into two broad categories from label
advertisement mode usage point of view:
1. Session mode-bound Applications
2. Session mode-independent Applications
3.2.1. Session mode-bound Applications
We define a "session mode-bound application" to be an application
which uses the negotiated label advertisement mode. This means that
the FEC-label binding exchange for such an LDP applications MUST use
the label advertisement mode negotiated for the LDP session.
The early LDP applications "Dynamic Label Switching for IP Prefixes"
and "Label-controlled ATM/FR" are included into this category.
3.2.2. Session mode-independent Applications
We define a "session mode-independent application" to be an
application which does not care about the negotiated label
advertisement mode. This means that the FEC-label binding, or any
other application data, exchange for such an LDP application 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 its
specification document. For example, [RFC6388] 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, are included
into this category of LDP applications.
3.2.2.1. Upstream Label Assignment
As opposed to downstream assigned label advertisement defined by
[RFC3031], [RFC6389] specification defines new mode of label
advertisement where label advertisement and distribution occurs for
upstream assigned labels.
Raza, et. al Expires January 2013 [Page 5]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
As stated earlier in this document, LDP base specification RFC-5036
only allows specifying Downstream-Unsolicited or Downstream-on-Demand
mode. This means that any LDP application that requires upstream
assigned label advertisement also falls under the category of Session
mode-independent application.
3.3. Unacceptable label advertisement mode
The procedures related to unacceptable label advertisement mode, as
defined in RFC-5036 section 3.5.3, continue to apply for any "mode-
bound" FEC/application. For a "mode-independent" FEC/application,
mode negotiation does not apply and hence both LSRs MUST operate in
the mode specified for the given application by the respective
specification.
If a session is jointly shared amongst mode-bound and mode-
independent FEC/applications, session will not be established if the
label advertisement mode is unacceptable (between the LSRs) for a
given mode-bound FEC/application type. This is inline with RFC-5036
section 3.5.3 specification for unacceptable mode.
4. Clarification on Mode Applicability
To remove any ambiguity and conflict amongst different
specifications with regards to the use of LDP session's label
advertisement mode, we propose an update to LDP base specification
RFC-5036 to clarify the applicability of session's negotiated mode.
Furthermore, RFC-4447 specifies LDP extensions and procedures to
exchange label bindings for P2P PW FECs [RFC4447], and dictates the
use of Downstream-Unsolicited mode for an LDP session related to
L2VPN PW. This mode dictation creates a direct conflict in
situations when a PW LDP session is shared with an LDP application
with Downstream-on-Demand mode (such as Label switching Application
for IP prefixes). To remove such a conflict, we also propose an
update to a section of RFC-4447.
Raza, et. al Expires January 2013 [Page 6]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
4.1. Update to RFC-5036
The 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 new document specifying a new FEC MUST state the
applicability of the negotiated label advertisement discipline for
that FEC.
4.2. Update to RFC-4447
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".
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].
6. IANA Considerations
None.
7. References
7.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
Specification", RFC 5036, September 2007.
Raza, et. al Expires January 2013 [Page 7]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
[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.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
7.2. Informative References
[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,
Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using
LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,
March 2012.
[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for
P2MP and MP2MP LSPs", RFC 6388, November 2011.
[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
"Inter-Chassis Communication Protocol for L2VPN PE
Redundancy", draft-ietf-pwe3-iccp-08.txt, Work in
Progress, June 2012.
[RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, November 2011.
8. Acknowledgments
We acknowledge the authors of [RFC5036] and [RFC4447] since some of
the text in this document is borrowed from their specification. We
also acknowledge Eric Rosen and Rajiv Asati for their review and
input.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive,
Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com
Sami Boutros
Raza, et. al Expires January 2013 [Page 8]
Internet-Draft Applicability of LDP Label Advertisement Mode July 2012
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
Nicolai Leymann
Deutsche Telekom,
Winterfeldtstrasse 21-27,
10781 Berlin, Germany.
E-mail: N.Leymann@telekom.de
Raza, et. al Expires January 2013 [Page 9]
