MPLS Working Group Santosh Esale
INTERNET-DRAFT Raveendra Torvi
Intended Status: Proposed Standard Chris Bowers
Expires: October 4, 2014 Juniper Networks
April 2, 2014
Applications aware LDP Targeted Session
draft-esale-mpls-appl-aware-ldp-targeted-session-00
Abstract
Recent Targeted LDP applications such as Remote LFA and BGP auto
discovery FEC 129 pseudowire may automatically establish a targeted
LDP session to any LSR in the core network. The sender LSR has
information about the targeted applications to administratively
control initiation of the session. However the receiver LSR has no
such information to control the acceptance of this session. This
document defines a mechanism to advertise Targeted Application
Capability during session initialization. As the receiver LSR becomes
aware of targeted LDP applications, it may establish a limited number
of sessions for certain applications. In addition, each targeted
application is mapped to LDP FEC Elements to advertise only necessary
LDP FEC label bindings over the session.
Status of this Memo
This Internet-Draft is submitted to IETF 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Esale, et al. Expires October 4, 2014 [Page 1]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
Copyright and License Notice
Copyright (c) 2014 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
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Targeted Application Capability . . . . . . . . . . . . . . . . 4
3. Targeted Application Capability Procedures . . . . . . . . . . 5
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities . . . . . . . . . . . . . . 6
5. Targeted Application capability in LDP messages . . . . . . . . 8
5.1 TAC in LDP Initialization message . . . . . . . . . . . . . 8
5.2 TAC in LDP Capability message . . . . . . . . . . . . . . . 8
7. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Remote LFA Automatic Targeted session . . . . . . . . . . . 8
7.2 FEC 129 Auto Discovery Targeted session . . . . . . . . . . 9
7.3 LDP over RSVP and Remote LFA targeted session . . . . . . . 9
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 10
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1 Normative References . . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Esale, et al. Expires October 4, 2014 [Page 2]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
1 Introduction
LDP can use the extended discovery mechanism to establish a targeted
adjacency and subsequent session as described in [RFC5036]. An LSR
initiates extended discovery by sending the targeted Hello to a
specific address. The remote LSR decides either to accept or ignore
the Hello based on local configuration only. For an application such
as FEC 128 pseudowire and LDP over RSVP tunneling, the remote LSR is
configured with the source LSR address, so the remote LSR can use
that information to accept or ignore any given LDP Hello.
Applications such as remote LFA and FEC 129 pseudowire automatically
initiate asymmetric extended discovery to any LSR in the network
based on local state. In these applications, the remote LSR is not
explicitly configured with the source LSR address, so the remote LSR
either responds to all LDP requests or ignores all LDP requests.
In addition, since the session is initiated and established after
adjacency formation, the receiver LSR has no targeted application
information to choose the targeted applications it would like to
support. While the sender LSR may employ a limit per application on
locally initiated automatic targeted sessions, the receiver LSR
currently has no mechanism to apply a similar limit on the incoming
targeted sessions. Also, the receiver LSR does not know whether the
source LSR is establishing the session for a configured or an
automatic application.
This document proposes and describes a solution to advertise targeted
application capability, consisting of a targeted application list,
during initialization of a targeted session. It also defines a
mechanism to enable a new application and disable an old application
after session establishment. This capability advertisement provides
the remote LSR with the necessary information to control the targeted
sessions per application. For instance, an LSR may wish to accept all
FEC 129 targeted sessions but may only accept limited number of
Remote LFA targeted sessions.
Also, targeted applications may be mapped to LDP FEC type to
advertise specific application FECs only, avoiding the advertisement
of unnecessary FECs over the session.
1.1 Terminology
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].
Esale, et al. Expires October 4, 2014 [Page 3]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
2. Targeted Application Capability
An LSR MAY advertise that it is capable of negotiating a targeted
application list over a session by using the Capability Advertisement
as defined in [RFC5561].
A new optional capability TLV is defined, 'Targeted Application
Capability (TAC)'. Its encoding is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Targeted App. Cap.(IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+
| |
~ Targeted App. Cap. data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U: set to 1. Ignore, if not known.
F: Set to 0. Do not forward.
S: MUST be set to 1 and ignored on receipt.
Targeted Application Capability data:
A Targeted Applications Capability data consists of none, one or
more Targeted Application Elements. Its encoding is as follows:
Targeted Application Element(TAE)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targ. Appl. Id|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Targeted Application Identifier (TA-Id):
0x0001: LDPv4 Tunneling
0x0002: LDPv6 Tunneling
0x0003: mLDP Tunneling
0x0004: LDPv4 Remote LFA
0x0005: LDPv6 Remote LFA
0x0006: FEC 128 Pseudowire
0x0007: FEC 129 Pseudowire
Esale, et al. Expires October 4, 2014 [Page 4]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
E-bit: It indicates whether the sender is advertising or
withdrawing the Targeted Application. The E-bit value
is used as follows:
1 - The TAE is advertising the targeted application.
0 - The TAE is withdrawing the targeted application.
The length of TAC depends on the number of TAE elements. For
instance, if two TAE elements are added, the length is set to 5.
If both the peers advertise TAC, an LSR decides to establish or
close a targeted session based on the negotiated targeted application
element list.
3. Targeted Application Capability Procedures
At targeted session establishment time, an LSR MAY include a new
capability TLV, Targeted Application Capability (TAC) TLV, as an
optional TLV in the LDP Initialization message. The TAC TLV's
Capability data MUST consists of none, one or more Targeted
Application Element(TAE) each pertaining to a unique Targeted
Application Identifier(TA-Id). If the receiver LSR receives the same
TA-Id in more than one TAE element, it MUST discard the TAC TLV and
behave as if TAC TLV is not received. If the receiver LSR receives an
unknown TA-Id in a TAE element, it SHOULD silently ignore such a TAE
element and continue processing the rest of the TLV.
If the receiver LSR does not receive the TAC in the Initialization
message or it does not understand the TAC TLV, the TAC negotiation
MUST be considered unsuccessful and the session establishment MUST
proceed as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR
MUST generate its own TAC TLV with TAE elements consisting of unique
TA-Ids that it MAY support over the targeted session. If there is at
least one TAE element common between the TAC TLV it has received and
its own, the session MUST proceed to establishment as per [RFC5036].
If not, A LSR MUST send a 'Session Rejected/Targeted Application
Capability Mis-Match' Notification message to the peer and close the
session. The sender LSR playing the passive role in LDP session
establishment MAY destroy the corresponding targeted adjacency.
When the receiver LSR playing the active role in LDP session
establishment receives a 'Session Rejected/Targeted Application
Capability Mis-Match' Notification message, it MUST set its session
setup retry interval to a maximum value, as 0xffff. The session MAY
stay in non-operational state. When it detects a change in the sender
LSR configuration or local configuration pertaining to TAC TLV, it
Esale, et al. Expires October 4, 2014 [Page 5]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
MUST clear the session setup back off delay associated with the
session to re-attempt the session establishment.
When the sender LSR playing the active role in LDP session
establishment receives a 'Session Rejected/Targeted Application
Capability Mis-Match' Notification message, either it MUST set its
session setup retry interval to a maximum value, as 0xffff or it MUST
destroy the corresponding targeted adjacency with the session.
This leads to destruction of the session.
If it sets the session setup retry interval to maximum, the session
MAY stay in a non-operational state. When this LSR detects a change in
the receiver LSR configuration or its own configuration pertaining
to TAC TLV, it MUST clear the session setup back off delay associated
with the session to re-attempt the session establishment.
If it decides to destroy the associated targeted adjacency, the
session is destroyed on the sender as well as the receiver LSR. The
sender LSR MAY take appropriate actions if it is unable to bring up
the targeted session. For instance, if an automatic session intended to
support the Remote LFA application is rejected by the receiver LSR, the
sender LSR MAY inform the IGPs to calculate another PQ
node for the route or set of routes. More specific actions are a local
matter and outside the scope of this document.
After an LDP session has been established with TAC capability, the
sender and receiver LSR MUST distribute FEC label bindings for the
negotiated applications only. For instance, if the LDP session is
established for FEC 129 pseudowire, only FEC 129 label bindings
MUST be distributed over the session. Similarly, a LSR MUST request
FEC label bindings for the negotiated applications only.
If the Targeted Application Capability and Dynamic Capability, as
defined in RFC5561, are negotiated during session Initialization,
TAC MAY be re-negotiated after session establishment by sending the
updated TAC TLV in LDP Capability message. The Updated TLV MUST
consist of one or more TAE elements with E bit set or E bit off
to advertise or withdraw the new and old application respectively.
This MAY lead to advertisements or withdrawals of certain FEC types
over the session or destruction of the adjacency and subsequently
the session.
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities
As described in this document, the set of Targeted Application
Elements negotiated between two LDP peers advertising TAC represents
the willingness of both peers to advertise state information for a
Esale, et al. Expires October 4, 2014 [Page 6]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
set of applications. The set of applications negotiated by the TAC
mechanism is symmetric between the two LDP peers. In the absence of
further mechanisms, two LDP peers will both advertise state
information for the same set of applications.
As described in [I-D.draft-ietf-mpls-ldp-ip-pw-capability], State
Advertisement Control(SAC) TLV can be used by an LDP speaker to
communicate its interest or disinterest in receiving state
information from a given peer for a particular application. Two LDP
peers can use the SAC mechanism to create asymmetric advertisement of
state information between the two peers for any particular
application.
For a given LDP session, the TAC mechanism can be used without the
SAC mechanism, and the SAC mechanism can be used without the TAC
mechanism. It is useful to discuss the behavior when TAC and SAC
mechanisms are used on the same LDP session. The TAC mechanism takes
precedence over the SAC mechanism with respect to enabling
applications for which state information will be advertised. For an
LDP session using the TAC mechanism, the LDP peers MUST NOT advertise
state information for an application that has not been negotiated in
the most recent Targeted Application Elements list (referred to as an
un-negotiated application). This is true even if one of the peers
announces its interest in receiving state information that
corresponds to the un-negotiated application by sending a SAC TLV.
In other words, when TAC is being used, SAC cannot enable state
information advertisement for applications that have not been enabled
by TAC.
On the other hand, the SAC mechanism takes precedence over the TAC
mechanism with respect to disabling state information advertisements.
If an LDP speaker has announced its disinterest in receiving state
information for a given application to a given peer using the SAC
mechanism, its peer MUST NOT send state information for that
application, even if the two peers have negotiated that the
corresponding application via the TAC mechanism.
For the purposes of determining the correspondence between targeted
applications defined in this document and application state as
defined in [I-D.draft-ietf-mpls-ldp-ip-pw-capability] an LSR MAY
using the following mappings:
LDPv4 Tunneling - IPv4 Label switching
LDPv6 Tunneling - IPv6 Label switching
LDPv4 Remote LFA - IPv4 Label switching
LDPv6 Remote LFA - IPv6 Label switching
FEC 128 Pseudowire - P2P PW FEC128 signaling
FEC 129 Pseudowire - P2P PW FEC129 signaling
Esale, et al. Expires October 4, 2014 [Page 7]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
An LSR MAY map Targeted Application to LDP capability as follows:
mLDP Tunneling - P2MP Capability, MP2MP Capability
5. Targeted Application capability in LDP messages
5.1 TAC in LDP Initialization message
1. The S-bit of the Targeted Application Capability parameter MUST be
set to 1 to advertise Targeted Application Capability and SHOULD be
ignored on the receipt. The E-bit of the Targeted Application
Element MUST be set to 1 to enable Targeted application.
2. An LSR MAY add State Control Capability by mapping Targeted
Application element to State Advertisement Control (SAC) Elements
as defined in Section 4.
3. The LSR MAY add a different Hold time value for an automatic targeted
session.
5.2 TAC in LDP Capability message
1. The S-bit of Targeted Application Capability is set to 1 and ignored
on receipt.
2. If there is no common Targeted Application element between its new
TAC and peers TAC, the LSR MUST send a 'Session Rejected/Targeted
Application Capability Mis-Match 'Notification message and close
the session.
3. If there is a common Targeted Application Element, a LSR MAY
also update State Advertisement Control Capability as per
Section 4 and send these capabilities in a Capability message
to the peer.
4. A receiving LSR processes the Capability message and its Targeted
Applications Capability TLV. The S-bit is ignored on receipt.
5. Process a List of Targeted Application Elements from capability
data with E-bit set to 1 to construct peers Targeted Application
Capability.
7. Use cases
7.1 Remote LFA Automatic Targeted session
An LSR determines that it needs to form a automatic targeted session
Esale, et al. Expires October 4, 2014 [Page 8]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
to remote PQ node based on IGP calculation as described in [I-
D.draft-ietf-rtgwg-remote-lfa] or some other mechanism, which is
outside the scope of this document. The LSR forms the targeted
adjacency and during session setup, constructs an Initialization
message with Targeted Applications Capability (TAC) with Targeted
Application Element (TAE) as Remote LFA. The receiver LSR processes
the LDP Initialization message and verifies whether it is configured
to accept a Remote LFA targeted session. If it is, it MAY further
verify that establishing such a session does not exceed the
configured limit for Remote LFA sessions. If all these conditions are
met, the receiver LSR may respond back with an Initialization message
with TAC corresponding to Remote LFA, and subsequently the session
may be established.
After the session has been established with TAC capability, the
sender and receiver LSR distribute IPv4 or IPv6 FEC label bindings
over the session. Further, the receiver LSR may determine that it
does not need these FEC label bindings. So it may disable the receipt
of these FEC label bindings by mapping targeted application element
to state control capability as described in section 4.
7.2 FEC 129 Auto Discovery Targeted session
BGP auto discovery or other mechanisms outside the scope of this
document MAY determine whether an LSR needs to initiate an auto-
discovery targeted session with a border LSR. Multiple LSRs MAY try
to form an auto-discovery LDP targeted session with a border LSR. So
a service provider may want to limit the number of auto-discovery
targeted sessions a border LSR MAY accept. As described in Section 3,
LDP MAY convey Targeted Applications with TAC TLV to border LSR. A
border LSR may establish or reject the session based on local
administrative policy. Also, as the receiver LSR would be aware of
targeted application, it can also employ an administrative policy for
security. For instance, it can employ a policy 'accept all auto-
discovered session from source-list'.
Moreover, the sender and receiver LSR MUST exchange FEC 129
application states only over the targeted session, i.e. FEC 129 label
bindings only.
7.3 LDP over RSVP and Remote LFA targeted session
A LSR may want to establish a targeted session to a remote LSR for
LDP over RSVP tunneling and Remote LFA. The sender LSR may add both
these applications as a unique Targeted Application Element in the
Targeted Application Capability data of a TAC TLV. The receiver LSR
MAY have reached a configured limit for accepting automatic targeted
sessions for Remote LFA, but it may also be configured to accept LDP
Esale, et al. Expires October 4, 2014 [Page 9]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
over RSVP tunneling. In this case, the targeted session is formed for
both LDP over RSVP and Remote LFA applications as both needs same
FECs - IPv4 and/or IPv6.
Also, the sender and the receiver LSR MUST distributes IPv4 and or
IPv6 FEC label bindings only over the session.
8 Security Considerations
The Capability procedure described in this document will apply and
does not introduce any change to LDP Security Considerations section
described in [RFC5036].
9 IANA Considerations
This document requires the assignment of a new code point for a
Capability Parameter TLVs from the IANA managed LDP registry "TLV
Type Name Space", corresponding to the advertisement of the Targeted
Applications capability. IANA is requested to assign the lowest
available value after 0x050B.
Value Description Reference
----- -------------------------------- ---------
TBD1 Targeted Applications capability [This draft]
This document requires the assignment of a new code point for a
status code from the IANA managed registry "STATUS CODE NAME SPACE",
corresponding to the notification of session Rejected/Targeted
Application Capability Mis-Match. IANA is requested to assign the
lowest available value after 0x0000004B.
Value Description Reference
----- -------------------------------- ---------
TBD2 Session Rejected/Targeted
Application Capability Mis-Match [This draft]
This document also creates a new name space 'the LDP Targeted
Application Element type' that is to be managed by IANA. The range is
0-65535, with the following values requested in this document.
0x0000: Reserved
0x0001: LDPv4 Tunneling
0x0002: LDPv6 Tunneling
0x0003: mLDP Tunneling
0x0004: LDPv4 Remote LFA
0x0005: LDPv6 Remote LFA
Esale, et al. Expires October 4, 2014 [Page 10]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
0x0006: FEC 128 Pseudowire
0x0007: FEC 129 Pseudowire
The allocation policy for this space is 'Standards Action with Early
Allocation'.
10. Acknowledgments
The authors wish to thank Nischal Sheth, Hassan Hosseini and Kishore
Tiruveedhula for doing the detailed review. Thanks to Manish Gupta
and Martin Ehlers for their input to this work and for many helpful
suggestions.
11 References
11.1 Normative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"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.
[I-D.draft-ietf-mpls-ldp-ip-pw-capability] Kamran Raza, Sami Boutros,
"Disabling IPoMPLS and P2P PW LDP Application's State
Advertisement", draft-ietf-mpls-ldp-ip-pw-capability-06
(work in progress), December 19, 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997..
11.2 Informative References
[I-D.draft-ietf-rtgwg-remote-lfa] S. Bryant, C. Filsfils, S.
Previdi,M. Shand, "Remote LFA FRR", draft-ietf-rtgwg-
remote-lfa-04 (work in progress), November 22, 2013.
[RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning,
Auto-Discovery, and Signaling in Layer 2 Virtual Private
Networks (L2VPNs)"
[RFC4762] M. Lasserre, and V. Kompella, "Virtual Private LAN Service
VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron,
Esale, et al. Expires October 4, 2014 [Page 11]
INTERNET DRAFT <Applications aware LDP targeted session> April 2, 2014
"Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
Authors' Addresses
Santosh Esale
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: sesale@juniper.net
Raveendra Torvi
Juniper Networks
10 Technology Park Drive.
Westford, MA 01886
US
EMail: rtorvi@juniper.net
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: cbowers@juniper.net
Esale, et al. Expires October 4, 2014 [Page 12]