Internet DRAFT - draft-pdutta-mpls-multi-ldp-instance
draft-pdutta-mpls-multi-ldp-instance
MPLS Working Group P. Dutta
Internet-Draft M. Aissaoui
Intended status: Standards Track Alcatel-Lucent
Expires: October 7, 2012 April 05, 2012
Multiple LDP Instances
draft-pdutta-mpls-multi-ldp-instance-00
Abstract
This document defines an extension to Label Distribution Protocol
(LDP) [RFC5036] for implementation of multiple LDP instances in a
network node, where all such instances share the common data plane.
Multiple LDP instances provide a method for operators for fate
separation of various LDP FEC Types as well as for network
segmentation. The methods defined in this extension are backward
compatible with procedures defined in [RFC5036]
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
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
Dutta & Aissaoui Expires October 7, 2012 [Page 1]
Internet-Draft Multi-Instance LDP April 2012
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. Multiple LDP Instances . . . . . . . . . . . . . . . . . . . . 4
2.1. Procedures for multi-instance peering . . . . . . . . . . 4
2.1.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Case 3 . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Case 4 . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Detection of multi-instance peering . . . . . . . . . . . . . 8
4. LDP Address Distribution with multi-instance peering . . . . . 9
5. LDP State Sharing between instances . . . . . . . . . . . . . 9
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Dutta & Aissaoui Expires October 7, 2012 [Page 2]
Internet-Draft Multi-Instance LDP April 2012
1. Introduction
The Multi-Protocol Label Switching (MPLS) architecture is described
in [RFC3031]. Label Distribution Protocol (LDP) is a signaling
protocol for setup and maintenance of MPLS LSPs (Label Switched
Paths) and the protocol specification is defined in [RFC5036].
Two Label Switched Routers (LSR) that use LDP to exchange label/FEC
mapping information are known as "LDP Peers" with respect to that
information, and we speak of there being an "LDP Session" between
them. A single LDP session allows each peer to learn the other's
label mappings. Each LSR is indentified by an LDP identifier. An
LDP Identifier is a six octet quantity used to identify an LSR label
space. The 4 octets identify the LSR and is a globally unique value,
such as a 32-bit router Id assigned to the LSR. The last two octets
identify a specific label space within the LSR. The last two octets
of LDP Indentifers for platform-wide label spaces are always both
zero. This document uses the following representation for LDP
Indentifiers:
<LSR Id> : <label space id>
e.g, lsr171:0, lsr19:2 etc
As per [RFC5036] an LSR that manages and advertises multiple label
spaces uses a different LDP Identifier for each such label space.
This means for a single label space there can be only one router-id
that is can be assigned to the node that exclusively owns that label
space. For example, it is not possible to have two LSRs like
lsr100:0 and lsr200:0 to be created in the a single node.
A LDP peering session between two LSRs may exchange labels for
setting up LSPs that may belong to different FEC types. Operators
may need the flexiblity for fate separation of different FEC types in
LDP protocol signaling when all such fec types share the same common
label space. This is not possible with the current paradigm of
single peering session between two LSRs and it requires one session
per fate separated group of FEC types to exchange labels. Thus
multiple LDP sessions are required between two peering nodes. One
example could be fate separation between IP transport network and the
overlay network of Pseudowires (PW). Procedures for PW set-up and
maintenance using LDP are defined in [RFC4447]. It may be also
desirable for fate separation IPv4 and IPv6 LSP set-up and
maintenance in LDP in case of which two separate LDP sessions need to
be formed between two peering nodes.
Although [RFC5036] does not specify that the 4 byte router-id of the
LDP identifier be routable IP addresses, for various operational
Dutta & Aissaoui Expires October 7, 2012 [Page 3]
Internet-Draft Multi-Instance LDP April 2012
simplicity implementations may map the 32 bit router-id to a IPv4
address configured in the node which is routable. In that way
uniqueness of the 4 byte router-id can be achieved over a single
routing domain. Interior Gateway Protocols (IGPs) like OSPF provide
the option of creation of multiple instances for segmentation of a
network into multiple routing domains. When LDP is deployed in such
networks it is required to segment LDP network to align with multiple
routing domains. When a node is connected to multiple such domains,
LDP peering sessions over all such domains cannot use a common IPv4
router-id which is local to that node, since the IPv4 mapped
router-id may not be routable across all such domains for security
purposes. There are applications such as BGP Autodiscovery of L2VPNs
or Dynamic MS-PW set-up that may auto-instantiate Targeted LDP
sessions where BGP IPv4 next-hop addresses for respective NLRIs are
mapped to peer LDP identifiers. Suc next-hop addresses may not be
routable between two routing domains.Thus there is need to host
multiple LSRs by a network node that shares the same label space but
each with unique router-ids.
This document describes a method to implement multiple instances of
LDP in a network node that shares same label space. The method is
generic and is backward compatible with nodes that supports
procedures defined in [RFC5036] but does not support the procedures
defined in this document. The procedures defined in this document
would be referred as "Multi-Instance LDP".
2. Multiple LDP Instances
The solution defines the concept of implementing multiple LDP
instances on a single network node that shares the single label space
and thus shares the common data plane. Each such LDP instance is
identified by a unique 4 byte router-id but same label space. Since
the multi-instance procedures use same LDP Indentifer as defined in
[RFC5036], it makes the node running multiple instances to be
backward compatible with the node that support the multi-instance LDP
procedures.
2.1. Procedures for multi-instance peering
When multiple LDP instances are set-up between two peering nodes for
fate separation reasons then there can be various ways Hello
adjacencies can be formed over the interfaces between the nodes.
Further multi-instance peering for fate separation results in
multiple parallel sessions between two peering nodes.
While running parallel multi-instance LDP sessions between two
peering nodes,
Dutta & Aissaoui Expires October 7, 2012 [Page 4]
Internet-Draft Multi-Instance LDP April 2012
1. Each peering sesssion MUST use separate transport address.
2. The FEC label mappings exchanged over each peering session MUST
be a disjoint set from one another.
The above rules does not apply between multi-instance LDP sessions
with different peering LDP nodes.
This document describes the following cases and defines the rules and
procedures with each case.
2.1.1. Case 1
Node - A Node - B
+-------------+ +--------------+
| LSR-A1:0--|============IF 1============|---LSR-B1:0 |
| \ | | / |
| LSR-A2:0 |============IF 2============| LSR-B2:0 |
+-------|-----+ +-------|------+
+---------------t-LDP Adj------------------+
Figure 1.
In this case the operator wants to separate the fate of FECs
exchanged between the nodes into two separate groups - Group 1 and
Group 2. For example Group 1 can contain all transport specific FEC
types such as IPV4 FEC Element Type and LDP Multi-point (MP) FEC
types etc. LDP Multi-point FEC types are described in [RFC6388] .
Group 2 contains various Pseudowire (PW) FEC types. PW setup and
maintenance using LDP is described in [RFC4447].
Two separate LSR-IDs are provisioned in each node - one LSR is
dedicated for FEC Group 1 and another for FEC Group 2.
There are two parallel interfaces between Node-A and Node-B as IF1
and IF2 respectively.
The traffic for LSPs set-up for FEC Group 1 may use both IF1 and IF2.
Thus both IF1 and IF2 would exchange Hello Packets using LSR-A1:0 and
LSR-A2:0 for setting up Hello adjacency for the LDP instance assigned
for FEC Group 1. The Hello messages exchanged over IF1 and IF2 MUST
carry the LDP Adjacency Capabilities for each FEC Types in FEC Group
1. LDP Adjacency Capabilities are defined in [LDP-ADJ-CAP]. This
would result in formation of a LDP session between Node A and Node B
for the instance indentified by LSR-A1:0 and LSR-B1:0 respectively.
The LDP session SHOULD be set-up with Capabilities of FEC Group 1.
Dutta & Aissaoui Expires October 7, 2012 [Page 5]
Internet-Draft Multi-Instance LDP April 2012
LDP session specific capability negotiation is described in [RFC5561]
A Targeted LDP (t-LDP) hello adjacency would be formed between node A
and node B using LSR-A2:0 and LSR-B2:0 respectively. The t-Ldp Hello
Messages exchanged between the nodes MUST carry the LDP Adjacency
Capabilities for each FEC Types in FEC Group 2. This would result in
a LDP session between Node A and Node B for the instance identified
by LSR-A2:0 and LSR-B2:0 respectively. The LDP session SHOULD be
set-up with capabilities of FEC Group 2.
2.1.2. Case 2
Node - A Node - B
+-------------+ +--------------+
| LSR-A1:0--|===========IF 1============|---LSR-B1:0 |
| x | | x |
| LSR-A2:0--|===========IF 2============|---LSR-B2:0 |
| | | |
| LSR-A3:0 |---------t-LDP Adj---------| LSR-B3:0 |
+-------------+ +--------------+
Figure 2.
This is a variant of case 1 where the operator may choose to further
separate the fate of IPV4 FEC Element Type and MP FEC Element types
into "Unicast" and "Multicast" Groups. Thus there are three FEC
Groups here and fate separation is required for all three FEC Groups.
FEC Group 1 : IPv4 FEC Element Type.
FEC Group 2: MP FEC Element Types.
FEC Group 3: PW FEC Element Types.
LDP Instance 1: The LDP instance with peering LSR-A1:0 and LSR-B1:0
are assigned for FEC Group 1.
LDP Instance 2: The LDP Instance with peering LSR-A2:0 and LSR-B2:0
are assigned for FEC Group 2.
LDP Instance 3: The LDP instance with peering LSR-A3:0 and LSR-B3:0
are assigned for FEC Group 3.
In this case, both IF1 and IF2 are associated with LDP instances 1
and 2. Each of IF1 and IF2 would originate two separate Hello
Messages using the same source IP address, one Hello Message for each
Dutta & Aissaoui Expires October 7, 2012 [Page 6]
Internet-Draft Multi-Instance LDP April 2012
instance . This would result in two hello adjacencies per interface
- one for Instance 1 and Instance 2. Each Hello Adjacncies SHOULD
advertise capabilities using rules described in case 1.
Such case may also arise when operator wants to do fate separation of
IPV4 and IPV6 LDP based LSPs but IF1 and IF2 are single stack
interfaces only - that is either IPV4 or IPV6. Thus an operator may
provision single stack interfaces IF1 and IF2 and yet can provision
fate separation of IPV4 and IPV6 LSPs.
The t-Ldp Hello Adjacency would be formed for LDP Instance 3 using
the PW Capabilities.
2.1.3. Case 3
Node - A Node - B
+-------------+ +--------------+
| LSR-A1:0--|============IF 1==============|---LSR-B1:0 |
| x | | x |
| LSR-A2:0--|============IF 2==============|---LSR-B2:0 |
| | | |
+-------------+ +--------------+
Figure 3.
This case a a variant of case 2 where, both interfaces IF1 and IF2
are dual-stack (IPV4 and IPV6) interfaces and operator wants fate
separation of IPV4 and IPV6 LSPs. Without loss of generality,
herebys IPv4 or IPV6 FECs may include all FEC types that are
associated with IPV4 or IPV6. For example,
[I-D.ietf-mpls-mldp-in-band-signaling] defines several in-band MP FEC
Types that may be classified into IPV6.
LDP Instance 1: The LDP instance with peering LSR-A1:0 and LSR-B1:0
are assigned for IPV4 FEC Types.
LDP Instance 2: The LDP Instance with peering LSR-A2:0 and LSR-B2:0
are assigned for IPV6 FEC Types.
Both the interfaces IF1 and IF2 are associated with each of the LDP
instances 1 and 2 respectively. Here the operator may choose to use
IPv4 addresses on the interfaces for sending Hello Messages for
Instance 1 and IPv6 addresses on the interfaces for sending Hello
Messages for Instance 2.
Dutta & Aissaoui Expires October 7, 2012 [Page 7]
Internet-Draft Multi-Instance LDP April 2012
2.1.4. Case 4
This case is variant of case 3 where inteface IF1 is dedicated for
IPV4 LSP Types and IF2 is dedicated for IPV6 LSP Types. This
provides fate-separation of both control plane and data plane for LSP
types.
3. Detection of multi-instance peering
While running parallel multi-instance LDP sessions between two
peering nodes, it is important to detect that such sessions with the
same peer node. If a node receives the same FEC label maping from
parallel multi-lsr peering sessions it may result in a loop for some
applications. An example of such application can be LDP based
Virtual Private LAN Service (VPLS)described [RFC4762]. So it is
important to detect and prevent such loops.
This document defines a new LDP Node-ID TLV that uniquely indentifies
the node that hosts multiple LDP instances. The LDP Node ID TLV is
OPTIONAL and is carried in LDP Hello Messages sent out by the node in
its Optional Parameters. The encoding of the LDP Node ID TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Node ID Tlv (TBD) | Length (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
The Value field is a 48 bit identifier and MUST be unique identifer
across the network.
1. All the multi-instance LDP LSRs MUST advertise the same LDP
Node-ID TLV in all Hello Messages originated by that node. One
example of the value can be a IEEE Vendor specific MAC Address that
can uniquely indentify a node in the network.
2. When a LSR receives a FEC label mapping from a peering session
but same FEC mapping has been already receiver over another peering
session associated with same Node-ID then the receiving LSR MUST send
a Label Release to the peering session with statuc code
Dutta & Aissaoui Expires October 7, 2012 [Page 8]
Internet-Draft Multi-Instance LDP April 2012
LOOP_DETECTED.
4. LDP Address Distribution with multi-instance peering
An LSR maintains learned labels in a Label Information Base (LIB).
When operating in Downstream Unsolicited mode, the LIB entry for an
address prefix associates a collection of (LDP Identifier, label)
pairs with the prefix, one such pair for each peer advertising a
label for the prefix. When the next hop for a prefix changes, the
LSR retrieves the label advertised by the new next hop from the LIB
for use in forwarding. To retrieve the label, the LSR should be able
to map the next hop address for the prefix to an LDP Identifier.
Similarly, when the LSR learns a label for a prefix from an LDP peer,
it should be able to determine whether that peer is currently a next
hop for the prefix to determine whether it needs to start using the
newly learned label when forwarding packets that match the prefix.
To make that decision, the LSR should be able to map an LDP
Identifier to the peer's addresses to check whether any are a next
hop for the prefix. To enable LSRs to map between a peer LDP
Identifier and the peer's addresses, LSRs advertise their addresses
using LDP Address and Withdraw Address messages as per procedures
defined in [RFC5036]
However while running multi-instance LDP peering between two nodes,
it is possible that all such sessions would distribute same set of
local addresses in each node. An implementation MAY segregate the
local address space in each node among the multiple ldp instances to
avoid duplication of address distribution.
5. LDP State Sharing between instances
TBD.
6. Applicability
This solution described in this document is applicable for multi-
instance LDP sessions for fate separation as well as for segmentation
of LDP network domains. More details would be covered in next
revisions of the document.
7. IANA Considerations
This document requests the following code points:
Dutta & Aissaoui Expires October 7, 2012 [Page 9]
Internet-Draft Multi-Instance LDP April 2012
- LDP Node-ID TLV type.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] describes the
security framework for MPLS networks. whereas [RFC5036] describes the
security considerations that apply to the base LDP specification.
The same security framework and considerations apply to the
capability mechansim described in this document.
9. Acknowledgements
The authors would like to thank Wim Henderickx for insightful
comments and probing questions.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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.
[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.
10.2. Informative References
[I-D.ietf-mpls-mldp-in-band-signaling]
Wijnands, I., Eckert, T., Leymann, N., and M. Napierala,
"Multipoint LDP in-band signaling for Point-to-Multipoint
and Multipoint- to-Multipoint Label Switched Paths",
Dutta & Aissaoui Expires October 7, 2012 [Page 10]
Internet-Draft Multi-Instance LDP April 2012
draft-ietf-mpls-mldp-in-band-signaling-05 (work in
progress), December 2011.
[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-09 (work
in progress), March 2010.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
Appendix A. An Appendix
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 11]
