Internet DRAFT - draft-pdutta-mpls-ldp-adj-capability
draft-pdutta-mpls-ldp-adj-capability
MPLS Working Group P. Dutta
Internet-Draft M. Aissaoui
Intended status: Standards Track Alcatel-Lucent
Expires: October 7, 2012 April 05, 2012
LDP Adjacency Capabilities
draft-pdutta-mpls-ldp-adj-capability-00
Abstract
This document defines method for negotiation of a set of capabilities
specific to a Label Distribution Protocol (LDP) Hello Adjacency. The
document uses the TLVs for the LDP Capabilities defined in [RFC5561]
to be used for exchanging capabilities over LDP Hello Adjacencies.
The Hello Adjacency capabilities can be thought of as "Traffic
Forwarding Capabilities" (TFC). Some capabilties already exist that
can be re-used for hello adjacency specific capabilities and it is
likely that some may be defined in future. This document defines the
mechanism to advertise LDP TFCs for a hello adjacency as well as
mechanism to enable and disable TFCs after a hello adjacency is
formed between LDP 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 October 7, 2012.
Copyright Notice
Dutta & Aissaoui Expires October 7, 2012 [Page 1]
Internet-Draft LDP Adj Capabilities April 2012
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. LDP Adjacency Capability . . . . . . . . . . . . . . . . . . . 5
3. Specifying Capabilities in LDP Hello Message . . . . . . . . . 5
4. Interaction between LDP Session and Adjacency Capabilities . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Dutta & Aissaoui Expires October 7, 2012 [Page 2]
Internet-Draft LDP Adj Capabilities April 2012
1. Introduction
[RFC5561] defines LDP Capabilities that are negotiated during
establishement of a LDP session between two peering Label Switch
Routers (LSR). LDP Capability advertisement provides means for an
LDP speaker to announce what it can receive and process over a LDP
session. For example, a speaker may exchange capabilities of
upstream label allocation, in bound label filtering or support of
various Forwarding Equivalence Classes (FECs). Each Capability Type
defines its own procedures, parameters and TLVs as described in
[RFC5561].
The LDP Capabilities defined in [RFC5561] is applicable to all hello
adjacencies associated with a LDP session. However, there may be
certain Capabilities (based on the specific Capability Type) that may
not be applicable to all hello adjacencies associated with a LDP
session between two LDP speakers. For example, It is possible that
there can be multiple Equal Cost Multi Path (ECMP) nterfaces between
two LDP speakers and thus multiple Hello Adjacencies are associated
with the session, one adjacency on each interface. Certain LDP
Capabilities negotiated through the session are applicable to all
such interfaces over which hello adjacencies are formed for the LDP
session, whereas some capabilities may be applicable only to a sub-
set of the Interfaces.
Such interface specific capabilities can be various FEC specific
capabilities exchanged over the peering session. It is possible that
a subset of the interfaces from the ECMP set may not be capable of
setting up the Label Switched Paths (LSPs) for certain FEC types that
have been exchanged over the peering session. Further an operator
may choose to exclude a subset of the ECMP interfaces from forwarding
or receiving traffic on certain FEC types for administrative policy
reasons. Such separation may be also required for fate separation of
LDP LSP types in data plane. Thus it is also required for
negotiation of capabilities at per interface level whether the
interface in a peer is capable or willing to forwarding traffic for a
FEC type on an interface. Two examples are described below:
+------+----------------L1------------------+-------+
| | | |
|LSR-A |----------------L2------------------| LSR-B |
| | | |
+------+----------------L3------------------+-------+
Figure 1: Hello Adjacencies over ECMP.
An LDP session is formed between LSR-A and LSR-B with hello
adjacencies over three ECMP interfaces respectively as IF1, IF2, and
IF3.
Dutta & Aissaoui Expires October 7, 2012 [Page 3]
Internet-Draft LDP Adj Capabilities April 2012
Case 1:
Let's assume that the hello adjacencies over IF1, IF2 and IF3 are
using either IPv4 or IPv6 based interfaces but not both (dual-stack).
Further the interface capability definitions are as follows:
All the three interfaces are capable of setting up LDP LSPs for IPv4
FEC Element Types.
Interface IF1 and IF2 are capable of setting up LDP Multi-point (MP)
LSPs defined in [RFC6388]
Interface IF2 and IF3 are capable of setting up LDP LSPs for IPv6 FEC
Element Types, or the operator decided to enable so.
Thus the LDP Hellos Messages exchanged over the interfaces need to
advertise capabilities as below in order to negotiate the LSP types
to be set-up on the interfaces.
The LDP Hello Messages exchanged over interface IF1 would advertise
IPv4 FEC Type Capability and the respective MP FEC Type Capabilities,
and would exclude IPv6 Capabilities.
The LDP Hello Messages exchanged over interface IF2 would advertise
IPV4 FEC Type Capability, MP FEC Type Capability and IPv6 FEC Type
Capability.
The LDP Hello Messages exchanged over interface IF3 would advertise
IPV4 FEC Type Capability and IPv6 FEC Type Capability, and would
exclude MP FEC Type Capability.
Case 2:
Node - A Node - B
+-------------+ +--------------+
| LSR-A1:0--|============IF 1==============|---LSR-B1:0 |
| x | | x |
| LSR-A2:0--|============IF 2==============|---LSR-B2:0 |
| | | |
+-------------+ +--------------+
Figure 2. Multiple LDP Instances for fate-separation of IPv4 and IPv6 LSPs
This case refers to section 2.1.3 described in
draft-pdutta-mpls-multi-ldp-instance-00. In this case, for fate
separation of IPv4 traffic and IPv6 traffic over dual stack
interfaces. In this case, all the ECMP inrerfaces are participating
in both the LDP instances, for IPv4 and IPv6 respectively. Each
Dutta & Aissaoui Expires October 7, 2012 [Page 4]
Internet-Draft LDP Adj Capabilities April 2012
inteface would originate two sets of Hello Messages. One set would
use IPv6 address on the interface as source address of the Hello
Message for the LSR assigned for IPV6. Another set would use IPv4
address on the interface as source address of the Hello Message for
the LSR assigned to IPv4.
In such a scenerio, it is required that the Hello Messages originated
by the IPv4 LDP instance would carry IPv4 FEC Capabilities only
whereas the Hello Messages originated by the IPv6 LDP instance would
carry IPv6 FEC Capabilities only.
2. LDP Adjacency Capability
The LDP Adjacency Capability or TFC advertisement mechanism operates
as follows:
- Each LDP speaker is assumed to implement a set of LDP capabilities
per Interface. At any time, a speaker may have none, one or more of
those capabilities enabled on an interface. When a capability is
enabled , the speaker advertises that capability associated on that
interface on the hello messages originated from that interface. By
advertising the capability over the interface, the speaker asserts
that it shall perform the protocol actions specified for the
capability on that interface. Unless the capability has been
advertised, the speaker will not perform protocol actions specified
for the capability on that interface.
- When a LDP speaker had advertised a set of capabilities on the
Hello Messages sent over an interface, then at any time the speaker
MAY announce changes to the advertised capabilities by reflecting
then change in subsequent Hello Messages.
3. Specifying Capabilities in LDP Hello Message
This document uses Capabilty Parameter TLV defined in [RFC5561] that
may be included as an OPTIONAL parameter in a LDP Hello Message to
advertise a Capability associated with an Interface. The Hello
Message can carry a set of such Capability Parameters TLVs, one for
each capability type.
The LDP speaker MUST NOT include more than one instance of a
Capability Parameter (as identified by the same TLV code point) in a
Hello Message. If an LDP speaker receives more than one instance of
the same Capability Parameter type in a message, it SHOULD accept the
first occurance of that Capability Type and ignore the next
occurences in that message.
Dutta & Aissaoui Expires October 7, 2012 [Page 5]
Internet-Draft LDP Adj Capabilities April 2012
To ensure backward compatibility, if a speaker receives a LDP Hello
Message without any Capability Parameter TLV then the receiver SHOULD
assume that the interface over which the hello adjacency is formed is
capable of the entire set of capabilities associated with the session
established with the peer. Such capability designer should specify
rules of that adjacency specific capability. For example, if a
received Hello Message does not carry any Capability Parameter then
receiver should assume that the interface is capable of sending or
receving of all FEC types advertised by the LDP session between the
speakers. If a Hello Message received over an interface carries one
or more Capability Parameters then receiver SHOULD use that interface
only as per the received capabilities.
For dual stack deployments involving IPv4 and IPv6 interfaces between
LDP peers, the IP Label Switching Capabilities defined in
[I-D.ietf-mpls-ldp-ip-pw-capability] can be used.
Note that it may be possible to define some capabilities in future
that may not be applicable to ber advertised by LDP session but only
over the Hello Adjacency. Such capabilities are out of scope of this
document.
4. Interaction between LDP Session and Adjacency Capabilities
Capabilities advertised via LDP session SHOULD be applicable to all
interfaces unless it is explicitly excluded on a given interface.
An LDP speaker MAY receive a set of Capabilities over a Hello
Adjacency with a peer but peer may not have included the Capability
set while establishing an LDP session. Such situation may arise in
multi-acess Interfaces where an LDP speaker may have established
sessions with multiple LDP peers. In such a case the LDP speaker
MUST not exercise the interface capabilities that are not included in
the LDP session with the peer.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document does not specify additional security implications to
Dutta & Aissaoui Expires October 7, 2012 [Page 6]
Internet-Draft LDP Adj Capabilities April 2012
what has been described in [RFC5561]
7. Acknowledgements
The authors would like to thank Wim Henderickx for the insightful
comments and probing questions.
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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
8.2. References
[I-D.ietf-mpls-ldp-ip-pw-capability]
Raza, K. and S. Boutros, "LDP IP and PW Capability",
draft-ietf-mpls-ldp-ip-pw-capability-01 (work in
progress), February 2012.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
Appendix A. An Appendix
Dutta & Aissaoui Expires October 7, 2012 [Page 7]
Internet-Draft LDP Adj Capabilities April 2012
Authors' Addresses
Pranjal Kumar Dutta
Alcatel-Lucent
701 E Middlefield Road
Mountain View, California 94043
USA
Phone:
Fax:
Email: pranjal.dutta@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-Lucent
600 May Road
Kanata, ON
Canada
Phone:
Fax:
Email: mustapha.aissaoui@alcatel-lucent.com
URI:
Dutta & Aissaoui Expires October 7, 2012 [Page 8]
