LDP Extensions for Multi Topology Routing
draft-ietf-mpls-ldp-multi-topology-04
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 , Ning So | ||
| Last updated | 2012-07-16 | ||
| Replaces | draft-zhao-mpls-ldp-multi-topology | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Early review
(of
-09)
by Joel Halpern
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7307 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-mpls-ldp-multi-topology-04
Internet Engineering Task Force Q. Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track L. Fang
Expires: December 16, 2012 C. Zhou
Cisco Systems
L. Li
China Mobile
N. So
Verizon Business
K. Kamran
Cisco Systems
July 16, 2012
LDP Extensions for Multi Topology Routing
draft-ietf-mpls-ldp-multi-topology-04.txt
Abstract
Multi-Topology (MT) routing is supported in IP networks with the use
of MT aware IGP protocols. 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 December 16, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhao, et al. Expires December 16, 2012 [Page 1]
Internet-Draft LDP Multi Topology Extensions July 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Terminology...................................................3
2. Introduction..................................................3
3. Signaling Extensions..........................................4
3.1. Topology-Scoped FEC.......................................4
3.2. New Address Families: MT IP...............................4
3.3. LDP FEC Elements with MT IP AF............................5
3.4. IGP MT-ID Mapping and Translation.........................6
3.5. LDP MT Capability Advertisement...........................6
3.6. Procedures................................................7
3.7. LDP Sessions..............................................8
3.8. Reserved MT ID Values.....................................9
4. MT Applicability on FEC-based features........................9
4.1. Typed Wildcard FEC Element................................9
4.2. End-of-LIB...............................................10
5. Error Handling...............................................10
5.1. MT Error Notification "Invalid Topology ID"..............10
6. Backwards Compatibility......................................10
7. MPLS Forwarding in MT........................................10
8. Security Consideration.......................................10
9. IANA Considerations..........................................11
10. Acknowledgement..............................................12
11. Contributors' Addresses......................................12
12. References...................................................13
Zhao, et al. Expires December 16, 2012 [Page 2]
Internet-Draft LDP Multi Topology Extensions July 2012
12.1. Normative References.....................................13
12.2. Informative References...................................13
Authors' Addresses...............................................13
Appendix.........................................................14
A. Requirements.................................................14
B. Application Scenarios........................................15
B.1. Simplified Data-plane...................................15
B.2. Using MT for P2P Protection.............................15
B.3. Using MT for mLDP Protection............................16
B.4. Service Separation......................................16
B.5. An Alternative inter-AS VPN Solution....................16
1. 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].
2. Introduction
Multi-Topology (MT) routing is supported in IP networks with the use
of MT aware IGP protocols. It would be advantageous for
communications Service Providers (CSP) to support Multiple Topologies
(MT) within MPLS environments (MPLS-MT). Beneficial MPLS-MT
deployment applications include:
o A CSP may want to assign varying 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.
Zhao, et al. Expires December 16, 2012 [Page 3]
Internet-Draft LDP Multi Topology Extensions July 2012
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 LDP procedures and protocol extensions
required to support MT routing in an MPLS environment.
3. Signaling Extensions
3.1. Topology-Scoped FEC
LDP assigns and binds a label to a 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
info. This infers 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: 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 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 | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix FEC Element Format [RFC5036]
Where "Prefix" encoding is as defined for given "Address Family", and
whose length (in bits) is 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 Family is:
Zhao, et al. Expires December 16, 2012 [Page 4]
Internet-Draft LDP Multi Topology Extensions July 2012
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 2: 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.
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 proposed 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 3: 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 December 16, 2012 [Page 5]
Internet-Draft LDP Multi Topology Extensions July 2012
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 4: 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 5: 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/carried in
LDP as-is and need no translation. However, there is a need for
translating reserved/special IGP MT-ID values to corresponding LDP
MT-IDs. The corresponding special/reserved LDP MT-ID values are
defined in later section 10.
3.5. LDP MT Capability Advertisement
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
after the LDP session is setup to announce LSR capability to support
MTR for the given IP address family.
Zhao, et al. Expires December 16, 2012 [Page 6]
Internet-Draft LDP Multi Topology Extensions July 2012
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 6: Multi-Topology Capability TLV Format
Where:
o U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 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: The length (in octets) of TLV.
The encoding of Typed Wcard FEC element, as defined in [RFC5561], is
defined in the Section 3.3 of this document.
3.6. Procedures
To announce its MT capability for an IP address family, LDP
FEC type, and Multi Topology, an LDP speaker MAY send "MT
Capability" including the exact Typed Wildcard FEC element with
corresponding "Address Family" field (i.e. set to "MT IP" for IPv4
and set to "MT IPv6" for IPv6 address family), corresponding "FEC
Zhao, et al. Expires December 16, 2012 [Page 7]
Internet-Draft LDP Multi Topology Extensions July 2012
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 MAY send "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
messages that include MT identifier to this LSR.
o If an LSR receives a Label Mapping message with 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 We propose to add a new notification event to signal the upstream
that the downstream is not capable.
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 may
initiate withdraw of all label mapping for existing LSPs of all
non-default MTs. Then it clears the S bit in MT capability TLV
and advertises via the Capability message.
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.7. LDP Sessions
Depending on the number of label spaces supported, if a single global
label space is supported, there will be one session supported for
each pair of peer, even there are multiple topologies supported
between these two peers. If there are different label spaces
supported for different topologies, which means that label spaces
overlap with each other for different MTs, then it is suggested to
establish multiple sessions for multiple topologies between these two
peers. In this case, multiple LSR-IDs need to be allocated
beforehand so that each multiple topology can have its own label
space ID.
Zhao, et al. Expires December 16, 2012 [Page 8]
Internet-Draft LDP Multi Topology Extensions July 2012
3.8. Reserved MT ID Values
Certain MT topologies are assigned to serve predetermined purposes:
Default-MT: Default topology. This corresponds to OSPF default IPv4
and IPv6, as well as ISIS default IPv4. A value of 0 is proposed.
ISIS IPv6 MT: ISIS default MT-ID for IPv6.
Wildcard-MT: This corresponds to All-Topologies. A value of 65535
(0xffff) is proposed.
We propose a new IANA registry "LDP Multi-Topology ID Name Space"
under IANA "LDP Parameter" namespace to keep 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 proposed in document do not require any extension
in 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 proposed format in section 4.3 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
"Wildcard Topology" MT-ID as defined in section 4.8. For instance,
upon local un-configuration of topology "x", an LSR may send wildcard
label withdraw with MT-ID "x" to withdraw all its labels from peer
that were advertised under the scope of topology "x". On the other
hand, upon some global configuration change, an LSR may send wildcard
label withdraw with MT-ID set to "Wildcard Topology" to withdraw all
its labels under all topologies from the peer.
Zhao, et al. Expires December 16, 2012 [Page 9]
Internet-Draft LDP Multi Topology Extensions July 2012
4.2. End-of-LIB
[RFC5919] specifies extensions and procedures for an LDP speaker to
signal its convergence for given FEC type towards a peer. The
procedures defined in [RFC5919] apply as-is to MT FEC element. This
means that an LDP speaker MAY signal its IP convergence using Typed
Wildcard FEC element, and its MT IP convergence per topology using MT
Typed Wildcard FEC element (as defined in earlier section).
5. Error Handling
The extensions defined in this document utilise the existing LDP
error handling defined in [RFC5036]. If an LSR receives an error
notification from a peer for an MPLS-MT 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 "Invalid Topology ID"
If an LSR has advertized an MT Capability TLV using the
Initialization message or Capability message, which includes Typed
Wildcard FEC Element(s) with specific MT-ID(s), 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.
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 the specified
signaling mechanisms do not provide any way for the data plane to
associate a given packet with a context-specific label space.
8. Security Consideration
No specific security issues with the proposed solutions are known.
The proposed extension in this document does not introduce any new
Zhao, et al. Expires December 16, 2012 [Page 10]
Internet-Draft LDP Multi Topology Extensions July 2012
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: 0x510 from LDP registry "TLV Type Name Space").
o New Status Code: "Multi-Topology Capability not supported"
(requested code point: 0x50 from LDP registry "Status Code Name
Space").
o New Status Code: "Invalid Topology ID" (requested code point: 0x51
from LDP registry "Status Code Name Space").
o New Status Code: "Unknown Address Family" (requested code point:
0x52 from LDP registry "Status Code Name Space").
Registry:
Range/Value E Description
-------------- --- ------------------------------
0x00000051 1 Invalid Topology ID
Figure 7: New Status Codes 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 8: Address Family Numbers
o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP
Parameter" namespace. The registry is defined as:
Range/Value Name
----------- ------------------------
0 Default Topology (ISIS and OSPF)
1-4095 Unassigned
4096 ISIS IPv6 routing topology (i.e. ISIS
MT ID #2)
4097-65534 Reserved (for future allocation)
65535 Wildcard Topology (ISIS or OSPF)
Figure 9: LDP Multi-Topology (MT) ID Name Space
Zhao, et al. Expires December 16, 2012 [Page 11]
Internet-Draft LDP Multi Topology Extensions July 2012
10. Acknowledgement
The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin,
Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai for
their valuable comments on this draft.
11. Contributors' Addresses
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
Huawei Technology
2330 Central Expressway
Santa Clara, CA 95050
US
Email: emily.chenying@huawei.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
Zhao, et al. Expires December 16, 2012 [Page 12]
Internet-Draft LDP Multi Topology Extensions July 2012
Daniel King
Old Dog Consulting
Email: E-mail: daniel@olddog.co.uk
12. References
12.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.
[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.
12.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
Zhao, et al. Expires December 16, 2012 [Page 13]
Internet-Draft LDP Multi Topology Extensions July 2012
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
Ning So
Verizon Business
2400 North Glenville Drive
Richardson, TX 75082
USA
Email: Ning.So@verizonbusiness.com
Kamran Raza
Cisco Systems
2000 Innovation Drive
Kanata, ON K2K-3E8, MA
Canada
Email: E-mail: skraza@cisco.com
Appendix A. Requirements
The following specific requirements and objectives have been defined
in order to provide the functionality described in Section 2
(Introduction), and facilitate CSP configuration and operation:
o Minimise configuration and operation complexity of MPLS-MT across
the network.
o The MPLS-MT solution SHOULD NOT require data-plane modification.
Zhao, et al. Expires December 16, 2012 [Page 14]
Internet-Draft LDP Multi Topology Extensions July 2012
o The MPLS-MT solution MUST support multiple topologies. Allowing a
an MPLS LSP to be established across a specific, or set of,
multiple topologies.
o Control and filtering of LSPs using explicitly including or
excluding multiple topologies MUST be supported.
o The MPLS-MT solution MUST be capable of supporting QoS mechanisms.
o The MPLS-MT solution MUST be backwards compatibility with existing
LDP message authenticity and integrity techniques, and loop
detection.
o Deployment of MPLS-MT within existing MPLS networks should be
possible, with nodes not capable of MPLS-MT being unaffected.
Appendix B. Application Scenarios
B.1. Simplified Data-plane
IGP-MT requires additional data-plane resources maintain multiple
forwarding for each configured MT. On the other hand, MPLS-MT does
not change the data-plane system architecture, if an IGP-MT is mapped
to an MPLS-MT. In case MPLS-MT, incoming label value itself can
determine an MT, and hence it requires a single NHLFE space. MPLS-MT
requires only MT-RIBs in the control-plane, no need to have MT-FIBs.
Forwarding IP packets over a particular MT requires either
configuration or some external means at every node, to maps an
attribute of incoming IP packet header to IGP-MT, which is additional
overhead for network management. Whereas, MPLS-MT mapping is
required only at the ingress-PE of an MPLS-MT LSP, because of each
node identifies MPLS-MT LSP switching based on incoming label, hence
no additional configuration is required at every node.
B.2. Using MT for P2P Protection
Mechanisms exist that can configure alternate path via backup-mt,
such that if primary link fails, then backup-MT can be used for
forwarding. However, such techniques require special marking of IP
packets that needs to be forwarded using backup-MT. MPLS-LDP-MT
procedures simplify the forwarding of the MPLS packets over backup-
MT, as MPLS-LDP-MT procedure distribute separate labels for each MT.
How backup paths are computed depends on the implementation, and the
algorithm. The MPLS-LDP-MT in conjunction with IGP-MT could be used
to separate the primary traffic and backup traffic. For example,
service providers can create a backup MT that consists of links that
are meant only for backup traffic. Service providers can then
establish bypass LSPs, standby LSPs, using backup MT, thus keeping
undeterministic backup traffic away from the primary traffic.
Zhao, et al. Expires December 16, 2012 [Page 15]
Internet-Draft LDP Multi Topology Extensions July 2012
B.3. Using MT for mLDP Protection
For the P2MP or MP2MP LSPs setup by using mLDP protocol, there is a
need to setup a backup LSP to have an end to end protection for the
primary LSP in the applications such as IPTV, where the end to end
protection is a must. Since the mLDP LSP is setup following the IGP
routes, the second LSP setup by following the IGP routes can not be
guaranteed to have the link and node diversity from the primary LSP.
By using MPLS-LDP-MT, two topology can be configured with complete
link and node diversity, where the primary and secondary LSP can be
set up independently within each topology. The two LSPs setup by
this mechanism can protect each other end-to-end.
B.4. Service Separation
MPLS-MT procedures allow establishing two distinct LSPs for the same
FEC, by advertising separate label mapping for each configured
topology. Service providers can implement QoS using MPLS-MT
procedures without requiring to create separate FEC address for each
class. MPLS-MT can also be used separate multicast and unicast
traffic.
B.5. An Alternative inter-AS VPN Solution
When the LSP is crossing multiple domains for the inter-as VPN
scenarios, the LSP setup process can be done by configuring a set of
routers which are in different domains into a new single domain with
a new topology ID using the LDP multiple topology. All the routers
belong this new topology will be used to carry the traffic across
multiple domains and since they are in a single domain with the new
topology ID, so the LDP LSP set up can be done without propagating
VPN routes across AS boundaries.
Zhao, et al. Expires December 16, 2012 [Page 16]
Internet-Draft LDP Multi Topology Extensions July 2012
Zhao, et al. Expires December 16, 2012 [Page 17]
Internet-Draft LDP Multi Topology Extensions July 2012