LDP Extensions for Multi Topology Routing
draft-ietf-mpls-ldp-multi-topology-09
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7307.
|
|
|---|---|---|---|
| Authors | Quintin Zhao , Luyuan Fang , Chao Zhou , Lianyuan Li , Syed Kamran Raza | ||
| Last updated | 2013-11-11 (Latest revision 2013-10-14) | ||
| Replaces | draft-zhao-mpls-ldp-multi-topology | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Early review
by Joel Halpern
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Loa Andersson | ||
| Shepherd write-up | Show Last changed 2013-10-16 | ||
| IESG | IESG state | Became RFC 7307 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Adrian Farrel | ||
| IESG note | |||
| Send notices to | mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-multi-topology@tools.ietf.org | ||
| IANA | IANA review state | IANA - Not OK |
draft-ietf-mpls-ldp-multi-topology-09
Internet Engineering Task Force Q. Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track L. Fang
Expires: April 18, 2014 C. Zhou
Cisco Systems
L. Li
China Mobile
K. Raza
Cisco Systems
October 14, 2013
LDP Extensions for Multi Topology Routing
draft-ietf-mpls-ldp-multi-topology-09.txt
Abstract
Multi-Topology (MT) routing is supported in IP networks with the use
of MT aware IGPs. In order to provide MT routing within
Multiprotocol Label Switching (MPLS) Label Distribution Protocol
(LDP) networks new extensions are required.
This document describes the LDP protocol extensions required to
support MT routing in an MPLS environment.
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 April 20, 2014.
Copyright Notice
Copyright (c) 2013 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
Zhao, et al. Expires April 20, 2014 [Page 1]
Internet-Draft LDP Multi Topology Extensions October 2013
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.
Zhao, et al. Expires April 20, 2014 [Page 2]
Internet-Draft LDP Multi Topology Extensions October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . . 5
3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . . 5
3.2. New Address Families: MT IP . . . . . . . . . . . . . . . 5
3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . . 6
3.4. IGP MT-ID Mapping and Translation . . . . . . . . . . . . 7
3.5. LDP MT Capability Advertisement . . . . . . . . . . . . . 7
3.5.1. Protocol Extension . . . . . . . . . . . . . . . . . . 7
3.5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 9
3.6. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 10
4. MT Applicability on FEC-based features . . . . . . . . . . . . 10
4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10
4.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. New FEC Sub-Types . . . . . . . . . . . . . . . . . . 11
4.3.2. MT LDP IPv4 FEC Sub-TLV . . . . . . . . . . . . . . . 12
4.3.3. MT LDP IPv6 FEC Sub-TLV . . . . . . . . . . . . . . . 12
4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. MT Error Notification for Invalid Topology ID . . . . . . 13
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13
7. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 14
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Manageability Considerations . . . . . . . . . . . . . . . . . 16
10.1. Control of Function and Policy . . . . . . . . . . . . . . 16
10.2. Information and Data Models . . . . . . . . . . . . . . . 16
10.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16
10.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16
10.5. Requirements On Other Protocols . . . . . . . . . . . . . 16
10.6. Impact On Network Operations . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Zhao, et al. Expires April 20, 2014 [Page 3]
Internet-Draft LDP Multi Topology Extensions October 2013
1. Introduction
Multi-Topology (MT) routing is supported in IP networks with the use
of MT aware IGPs. It would be advantageous for communications
Service Providers (CSP) to support Multiple Topologies (MT) within
MPLS environments (MPLS-MT). The benefits of MPLS-MT enabled
networks include:
o A CSP may want to assign varying Quality of Service (QoS) profiles
to traffic, based on a specific MT.
o Separate routing and MPLS domains may be used to isolated
multicast and IPv6 islands within the backbone network.
o Specific IP address space could be routed across an MT based on
security or operational isolation requirements.
o Low latency links could be assigned to an MT for delay sensitive
traffic.
o Management traffic could be separated from customer traffic using
multiple MTs, where the management traffic MT does not use links
that carries customer traffic.
This document describes the Label Distribution Protocol (LDP)
procedures and protocol extensions required to support MT routing in
an MPLS environment.
This document also updates RFC4379 by defining two new FEC types for
Label Switched Path (LSP) ping.
2. Terminology
This document uses MPLS terminology defined in [RFC5036]. Additional
terms are defined below:
o MT-ID: A 16 bit value used to represent the Multi-Topology ID.
o Default MT Topology: A topology that is built using the MT-ID
default value of 0.
o MT Topology: A topology that is built using the corresponding
MT-ID.
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].
Zhao, et al. Expires April 20, 2014 [Page 4]
Internet-Draft LDP Multi Topology Extensions October 2013
3. Signaling Extensions
3.1. Topology-Scoped Forwarding Equivalence Class (FEC)
LDP assigns and binds a label to a Forwarding Equivalence Class
(FEC), where a FEC is a list of one of more FEC elements. To setup
LSPs for unicast IP routing paths, LDP assigns local labels for IP
prefixes, and advertises these labels to its peers so that an LSP is
setup along the routing path. To setup MT LSPs for IP prefixes under
a given topology scope, the LDP "prefix-related" FEC element must be
extended to include topology information. This implies that MT-ID
becomes an attribute of Prefix-related FEC element, and all FEC-Label
binding operations are performed under the context of given topology
(MT-ID).
The following Subsection 3.2(New Address Families (AF): MT IP)
defines the extension required to bind "prefix-related" FEC to a
topology.
3.2. New Address Families: MT IP
The LDP base specification [RFC5036] (Section 4.1) defines the
"Prefix" FEC Element. The "Prefix" encoding is defined for a given
"Address Family" (AF), and has length (in bits) specified by the
"PreLen" field.
To extend IP address families for MT, two new Address Families named
"MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes
within a topology scope.
The format of data associated with these new Address Families are
described below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT IP Address Family Format
Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and
"MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16-
bit Topology ID for given address.
Zhao, et al. Expires April 20, 2014 [Page 5]
Internet-Draft LDP Multi Topology Extensions October 2013
Where 16-bit "MT-ID" field defines the Topology ID, and the
definition and usage of the rest fields in the FEC Elements are same
as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to
default topology and MUST be ignored on receipt so as to not cause
any conflict/confusion with existing non-MT procedures.
The defined FEC Elements with "MT IP" Address Family can be used in
any LDP message and procedures that currently specify and allow the
use of FEC Elements with IP/IPv6 Address Family.
3.3. LDP FEC Elements with MT IP AF
The following section specifies the format extensions of the existing
LDP FEC Elements. The "Address Family" of these FEC elements will be
set to "MT IP" or "MT IPv6".
The MT Prefix FEC element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MT Prefix FEC Element Format
Similarly, the MT mLDP FEC elements encoding is as follows, where the
mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8):
Zhao, et al. Expires April 20, 2014 [Page 6]
Internet-Draft LDP Multi Topology Extensions October 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MT mLDP FEC Element Format
The MT Typed Wildcard FEC element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MT Typed Wildcard FEC Element
3.4. IGP MT-ID Mapping and Translation
The non-reserved non-special IGP MT-ID values can be used and carried
in LDP without the need for translation. However, there is a need
for translating reserved or special IGP MT-ID values to corresponding
LDP MT-IDs. The corresponding special and reserved LDP MT-ID values
are requested In Section 9. (IANA Considerations).
3.5. LDP MT Capability Advertisement
3.5.1. Protocol Extension
We specify a new LDP capability, named "Multi-Topology (MT)", which
is defined in accordance with LDP Capability definition guidelines
[RFC5561]. The LDP "MT" capability can be advertised by an LDP
speaker to its peers either during the LDP session initialization or
Zhao, et al. Expires April 20, 2014 [Page 7]
Internet-Draft LDP Multi Topology Extensions October 2013
after the LDP session is setup to announce LSR capability to support
MT for the given IP address family. An LDP speaker MUST NOT send an
MT AF unless the peer has said it can handle it.
The MT capability is specified using "Multi-Topology Capability" TLV.
The "Multi-Topology Capability" TLV format is in accordance with LDP
capability guidelines as defined in [RFC5561]. To be able to specify
IP address family, the capability specific data (i.e. "Capability
Data" field of Capability TLV) is populated using "Typed Wildcard FEC
Element" as defined in [RFC5918].
The format of "Multi-Topology Capability" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Multi-Topology Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
~ Typed Wildcard FEC element(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multi-Topology Capability TLV Format
Where:
o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3.
(Signaling Extensions) of LDP Capabilities [RFC5561].
o Multi-Topology Capability: Capability TLV type (IANA assigned)
o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be
set to 0 or 1 in dynamic "Capability" message to advertise or
withdraw the capability respectively.
o Typed Wildcard FEC element(s): One or more elements specified as
the "Capability data".
o Length: length of Value field, starting from S bit, in octets.
o The encoding of Typed Wildcard FEC element, as defined in
[RFC5918], is defined in the section 3.3 (Typed Wildcard FEC
Element) of this document.
In the case that the LDP initialization message can not hold all the
MTs to be advertised, dynamic "Capability" message to advertise the
Zhao, et al. Expires April 20, 2014 [Page 8]
Internet-Draft LDP Multi Topology Extensions October 2013
capability" must be supported.
3.5.2. Procedures
To announce its MT capability for an IP address family, LDP FEC type,
and Multi Topology, an LDP speaker an LDP speaker sends an "MT
Capability" including the exact Typed Wildcard FEC element with
corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4
and set to "MT IPv6" for IPv6 address family), corresponding "FEC
Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding
"MT-ID". To announce its MT capability for both IPv4 and IPv6
address family, or for multiple FEC types, or for multiple Multi
Topologies, an LDP speaker an LDP speaker sends "MT Capability" with
one or more MT Typed FEC elements in it.
o The capability for supporting multi-topology in LDP can be
advertised during LDP session initialization stage by including
the LDP MT capability TLV in LDP Initialization message. After an
LDP session is established, the MT capability can also be
advertised or withdrawn using Capability message (only if "Dynamic
Announcement" capability [RFC5561] has already been successfully
negotiated).
o If an LSR has not advertised MT capability, its peer MUST NOT send
label mapping messages that include MT identifier to this LSR.
o If an LSR receives a Label Mapping message with an MT parameter
from downstream LSR-D and its upstream LSR-U has not advertised MT
capability, an LSP for the MT will not be established.
o If an LSR is changed from non-MT capable to MT capable, it sets
the S bit in MT capability TLV and advertises via the Capability
message. The existing LSP is treated as LSP for default MT (ID
0).
o If an LSR is changed from LDP-MT capable to non-MT capable, it
initiates withdraw of all label mapping for existing LSPs of all
non-default MTs. It also cleanup all the LSPs of all non-default
MTs locally. Then it clears the S bit in MT capability TLV and
advertises via the Capability message. When an LSR knows the peer
node is changed from LDP-MT capable to non-MT capable, it cleanup
all the LSPs of all non-default MTs locally and initiate withdraw
of all label mapping for existing LSPs of all non-default MTs.
Both sides of the nodes send label release to its peer once they
receive the label release messages even both sides have already
cleaned up all the LSPs locally.
Zhao, et al. Expires April 20, 2014 [Page 9]
Internet-Draft LDP Multi Topology Extensions October 2013
o If an LSR is changed from IGP-MT capable to non-MT capable, it may
wait until the routes update to withdraw FEC and release the label
mapping for existing LSPs of specific MT.
3.6. LDP Sessions
Since using different label spaces for different topologies would
imply significant changes to the data plane, a single global label
space is supported in this solution. There will be one session
supported for each pair of peer, even there are multiple topologies
supported between these two peers.
3.7. Reserved MT ID Values
Certain MT topologies are assigned to serve predetermined purposes.
In Section 9. (IANA Considerations), this document defines a new
IANA registry "LDP Multi-Topology ID Name Space" under IANA "LDP
Parameter" namespace to keep an LDP MT-ID reserved value.
If an LSR receives a FEC element with an "MT-ID" value that is
"Reserved" for future use (and not IANA allocated yet), the LSR must
abort the processing of the FEC element, and SHOULD send a
notification message with status code "Invalid MT-ID" to the sender.
4. MT Applicability on FEC-based features
4.1. Typed Wildcard FEC Element
[RFC5918] extends base LDP and defines Typed Wildcard FEC Element
framework. Typed Wildcard FEC element can be used in any LDP message
to specify a wildcard operation/action for given type of FEC.
The MT extensions defined in document do not require any extension to
procedures for Typed Wildcard FEC element, and these procedures apply
as-is to MT wildcarding. The MT extensions, though, allow use of "MT
IP" or "MT IPv6" in the Address Family field of the Typed Wildcard
FEC element in order to use wildcard operations in the context of a
given topology. The use of MT-scoped address family also allows us
to specify MT-ID in these operations.
The defined format in Section 3.3 (Typed Wildcard FEC Element) allows
an LSR to perform wildcard FEC operations under the scope of a
topology. If an LSR wishes to perform wildcard operation that
applies to all topologies, it can use a "Wildcard Topology" MT-ID.
For example, upon local configuration of topology "x", an LSR may
send a wildcard label withdraw request with MT-ID "x" to withdraw all
Zhao, et al. Expires April 20, 2014 [Page 10]
Internet-Draft LDP Multi Topology Extensions October 2013
its labels from the peer that advertised under the scope of topology
"x". Additionally, upon a global configuration change, an LSR may
send a wildcard label withdraw with the MT-ID set to "Wildcard
Topology" to withdraw all its labels under all topologies from the
peer.
4.2. End-of-LIB
[RFC5919] specifies extensions and procedures for an LDP speaker to
signal its convergence for a given FEC type towards a peer. The
procedures defined in [RFC5919] applies as-is to an MT FEC element.
This allows an LDP speaker to signal its IP convergence using Typed
Wildcard FEC element, and its MT IP convergence per topology using a
MT Typed Wildcard FEC element.
4.3. LSP Ping
[RFC4379] defines procedures to detect data-plane failures in MPLS
LSPs via LSP ping. That specification defines a "Target FEC Stack"
TLV that describes the FEC stack being tested. This TLV is sent in
an MPLS echo request message towards LSPs egress LSR, and is
forwarded along the same data path as other packets belonging to the
FEC.
"Target FEC Stack" TLV contains one or more sub-TLVs pertaining to
different FEC types. Section 3.2 of [RFC4379] defines Sub-Types and
format for the FEC. To support LSP ping for MT LDP LSPs, this
document defines following extensions to [RFC4379].
4.3.1. New FEC Sub-Types
We define two new FEC types for LSP ping:
o MT LDP IPv4 FEC
o MT LDP IPv6 FEC
We also define following new sub-types for sub-TLVs to specify these
FECs in the "Target FEC Stack" TLV of [RFC4379]:
Sub-Type Length Value Field
-------- ------ -----------------
TBA5 8 MT LDP IPv4 prefix
TBA6 20 MT LDP IPv6 prefix
Figure 6: new sub-types for sub-TLVs
Zhao, et al. Expires April 20, 2014 [Page 11]
Internet-Draft LDP Multi Topology Extensions October 2013
The rules and procedures of using these sub-TLVs in an MPLS echo
request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV
types in [RFC4379].
4.3.2. MT LDP IPv4 FEC Sub-TLV
The format of "MT LDP IPv4 FEC" sub-TLV to be used in a "Target FEC
Stack" [RFC4379] is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA5(MT LDP IPv4 FEC) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MT LDP IPv4 FEC sub-TLV
The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as
defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix
Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology
ID). The Length for this sub-TLV is 5.
4.3.3. MT LDP IPv6 FEC Sub-TLV
The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC
Stack" [RFC4379] is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA6(MT LDP IPv6 FEC) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MT LDP IPv6 FEC sub-TLV
The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as
Zhao, et al. Expires April 20, 2014 [Page 12]
Internet-Draft LDP Multi Topology Extensions October 2013
defined in [RFC4379]. In addition to "IPv6 prefix" and "Prefix
Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology
ID). The Length for this sub-TLV is 17.
4.3.4. Operation Considerations
To detect data plane failures using LSP Ping for a specific topology,
the router will initiate an LSP Ping request with the target FEC
stack TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request
packet. The Echo Request packet is sent with the label bound to the
IP Prefix in the topology. Once the echo request packet reaches the
target router, it will process the packet and perform checks for the
LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described
in [RFC4379] and respond according to [RFC4379] processing rules.
For the case that the LSP ping with return path not specified , the
reply packet must go through the default topology instead of the
topology where the Echo Request goes through.
5. Error Handling
The extensions defined in this document utilize the existing LDP
error handling defined in [RFC5036]. If an LSR receives an error
notification from a peer for a session, it terminates the LDP session
by closing the TCP transport connection for the session and
discarding all MT-ID label mappings learned via the session.
5.1. MT Error Notification for Invalid Topology ID
If an LSR has advertised an MT Capability TLV using the
Initialization message or Capability message, which includes Typed
Wildcard FEC elements with specific MT-IDs, and it receives an MT
message with a MT-ID which is not included in the supported list, it
should response this "Invalid Topology ID" status code.
6. Backwards Compatibility
The MPLS-MT solution is backwards compatible with existing LDP
enhancements defined in [RFC5036], including message authenticity,
integrity of message, and topology loop detection.
The legacy node which does not support MT should not receive any MT
related LDP messages. In case the bad things does happen, according
to [RFC5036], processing of such message should be aborted.
Zhao, et al. Expires April 20, 2014 [Page 13]
Internet-Draft LDP Multi Topology Extensions October 2013
7. MPLS Forwarding in MT
Although forwarding is out of the scope of this draft, we include
some forwarding consideration for informational purpose here.
The specified signaling mechanisms allow all the topologies to share
the platform-specific label space; this is the feature that allows
the existing data plane techniques to be used; and there is no way
for the data plane to associate a received packet with any one
topology, meaning that topology-specific label spaces cannot be used.
8. Security Consideration
No specific security issues with the defined solutions are known.
The defined extensions in this document do not introduce any new
security considerations beyond that already apply to the base LDP
specification [RFC5036] and [RFC5920].
9. IANA Considerations
The document introduces following new protocol elements that require
IANA consideration and assignments:
o New LDP Capability TLV: "Multi-Topology Capability" TLV (requested
code point: TBA1 from LDP registry "TLV Type Name Space").
o New Status Code: "Multi-Topology Capability not supported"
(requested code point: TBA2 from LDP registry "Status Code Name
Space"). This status code is only used by node that supports MT
when decided to withdraw this capability.
o New Status Code: "Invalid Topology ID" (requested code point: TBA3
from LDP registry "Status Code Name Space").
Registry:
Range/Value Description
-------------- ------------------------------
TBA1 Multi-Topology Capability
TBA2 Multi-Topology Capability not supported
TBA3 Invalid Topology ID
Zhao, et al. Expires April 20, 2014 [Page 14]
Internet-Draft LDP Multi Topology Extensions October 2013
Figure 9: New Code Points for LDP Multi Topology Extensions
o New address families under IANA registry "Address Family Numbers":
- MT IP: Multi-Topology IP version 4 (requested codepoint: 26)
- MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27)
Figure 10: Address Family Numbers
o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP
Parameter" namespace. The allocation policies for this registry
are:
Range/Value Purpose Reference
----------- ------------------------------------- ---------
0 Default/standard topology
1 IPv4 in-band management
2 IPv6 routing topology
3 IPv4 multicast topology
4 IPv6 multicast topology
5 IPv6 in-band management
6-3995 Reserved for future IGP topologies
3996-4095 Reserved for IGP experimental topologies
4096-4127 Reserved for LDP topologies
4128-65534 Reserved for LDP experimental topologies
65535 Wildcard Topology
Figure 11: LDP Multi-Topology (MT) ID Name Space
o New Sub-TLV Types for LSP ping: Following new sub-type values
under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry, and "TLVs and sub-TLVs" sub-registry.
Sub-Type Value Field
-------- -----------
TBA4 MT LDP IPv4 prefix
TBA5 MT LDP IPv6 prefix
Figure 12: New Sub-TLV Types for LSP ping
Zhao, et al. Expires April 20, 2014 [Page 15]
Internet-Draft LDP Multi Topology Extensions October 2013
IANA should allocate the next available numbers for these TBAs.
10. Manageability Considerations
10.1. Control of Function and Policy
There are capabilities that should be configurable to enable good
manageability. One such example is to allow enable or disable LDP
Multi-Topology capability. It is assumed that the mapping of the LDP
MT ID and IGP MT ID is manually configured on every router by
default. If an automatic mapping between IGP MT IDs and LDP MT IDs
is needed, there must be explicit configuration to do so.
10.2. Information and Data Models
draft-li-mpls-ldp-mt-mib.txt describes the PCEP MIB, there is no new
MIB Objects for this document.
10.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements.
10.4. Verify Correct Operations
If an operator is trying to debug LDP MT enabled network and wants to
make the association between the LDP label advertisement and the IGP
routing advertisement, then the user must understand the mapping
mechanism to convert the IGP MT ID to the LDP MT ID. This type of
mapping mechanisms is out of the scope of this document.
10.5. Requirements On Other Protocols
If the LDP MT ID has an implicit dependency on IGP MT ID, then the
corresponding IGP MT feature/s need to be supported.
10.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations.
11. Contributors
Ning So
Tata Communications
Zhao, et al. Expires April 20, 2014 [Page 16]
Internet-Draft LDP Multi Topology Extensions October 2013
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ning.so@tatacommunications.com
Raveendra Torvi
Juniper Networks
10, Technoogy Park Drive
Westford, MA 01886-3140
US
Email: rtorvi@juniper.net
Huaimo Chen
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: huaimochen@huawei.com
Emily Chen
2717 Seville Blvd, Apt 1205,
Clearwater, FL 33764
US
Email: emily.chen220@gmail.com
Chen Li
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lichenyj@chinamobile.com
Lu Huang
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: huanglu@chinamobile.com
Daniel King
Old Dog Consulting
Zhao, et al. Expires April 20, 2014 [Page 17]
Internet-Draft LDP Multi Topology Extensions October 2013
Email: E-mail: daniel@olddog.co.uk
Zhenbin Li
Huawei Technology
2330 Central Expressway
Santa Clara, CA 95050
US
Email: zhenbin.li@huawei.com
12. Acknowledgement
The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin,
Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun
Chai,pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel,
Alia Atlas and Loa Anderson for their valuable comments on this
draft.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[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.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, August 2010.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919,
August 2010.
Zhao, et al. Expires April 20, 2014 [Page 18]
Internet-Draft LDP Multi Topology Extensions October 2013
13.2. Informative References
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Luyuan Fang
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
US
Email: lufang@cisco.com
Chao Zhou
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
US
Email: czhou@cisco.com
Lianyuan Li
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lilianyuan@chinamobile.com
Zhao, et al. Expires April 20, 2014 [Page 19]
Internet-Draft LDP Multi Topology Extensions October 2013
Kamran Raza
Cisco Systems
2000 Innovation Drive
Kanata, ON K2K-3E8, MA
Canada
Email: E-mail: skraza@cisco.com
Zhao, et al. Expires April 20, 2014 [Page 20]