One document matched: draft-iwijnand-mpls-mldp-multi-topology-03.txt
Differences from draft-iwijnand-mpls-mldp-multi-topology-02.txt
MPLS Working Group IJsbrand Wijnands
Internet Draft Cisco Systems, Inc.
Intended status: Standards Track
Expires: December 19, 2013 Kamran Raza
Cisco Systems, Inc.
June 20, 2013
mLDP Extensions for Multi Topology Routing
draft-iwijnand-mpls-mldp-multi-topology-03.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 19, 2013.
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
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
Wijnands, et. al Expires December 2013 [Page 1]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
The Multi-Topology Routing (MTR) enables service differentiation
through class-based forwarding. IGP protocols (OSPF and IS-IS) have
already been extended to setup MTR. In order to deploy mLDP in an
MTR network, mLDP is also required to become topology-aware. This
document specifies extensions to mLDP to support Multi-Topology
Routing.
Table of Contents
1. Glossary ................................................... 3
2. Introduction ............................................... 3
3. Conventions used in this document .......................... 4
4. MT-Scoped mLDP FECs ........................................ 4
4.1. MP FEC Extensions for MT .............................. 4
4.1.1. MP FEC Element ................................. 4
4.1.2. MT IP Address Families ......................... 5
4.1.3. MT MP FEC Element .............................. 6
4.2. Topology IDs .......................................... 7
5. MT Multipoint Capability .................................... 7
6. MT Applicability on FEC-based features ...................... 8
6.1. Typed Wildcard MP FEC Elements ......................... 8
6.2. End-of-LIB ............................................. 8
7. Topology-Scoped Forwarding .................................. 9
7.1. Upstream LSR selection ................................. 9
7.2. Downstream forwarding interface selection .............. 9
8. LSP Ping Extensions ......................................... 9
9. Security Considerations .................................... 10
10. IANA Considerations ....................................... 10
11. References ................................................ 11
11.1. Normative References ................................ 11
11.2. Informative References .............................. 11
12. Acknowledgments ........................................... 12
Wijnands, et. al Expires December 2013 [Page 2]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
1. Glossary
MT - Multi-Topology
MT-ID - Multi-Topology Identifier
MTR - Multi-Topology Routing
IGP - Interior Gateway Protocol
MP - Multipoint (P2MP or MP2MP)
mLDP - Multipoint LDP
P2MP - Point-to-Multipoint
MP2MP - Multipoint-to-Multipoint
FEC - Forwarding Equivalence Class
LSP - Label Switched Path
2. Introduction
The Multi-Topology Routing (MTR) enables service differentiation
through class-based forwarding. For example, MTR can be used to
define separate IP topologies for voice, video, and data traffic
classes. To support MTR, an IGP maintains independent IP topologies,
termed as "Multi-Topologies" (MT), and computes/installs routes per
topology. OSPF extensions [RFC4915] and ISIS extensions [RFC5120]
specify the MT extensions under respective IGPs. To support IGP MT,
similar LDP extensions [MT-LDP] have been proposed to make LDP MT-
aware and be able to setup unicast Label Switched Paths (LSPs) along
IGP MT routing paths.
Multipoint LDP (mLDP) refers to extensions in LDP to setup multi-
point LSPs, point-to-multipoint (P2MP) or multipoint-to-multipoint
(MP2MP), by means of set of extensions and procedures defined in
[RFC6388]. In order to work in an MTR network to take advantage of
MTs, it is a natural extension to make mLDP become MT-aware. This
document specifies the extensions to mLDP to support IGP Multi-
Topology Routing (MTR).
Wijnands, et. al Expires December 2013 [Page 3]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
3. Conventions used in this document
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
4. MT-Scoped mLDP FECs
As defined in [MT-LDP], the Multi-Topology Identifier (MT-ID) is an
identifier that is used to associate an LSP with a certain MTR
topology. In the context of MP LSPs, this identifier is part of the
mLDP FEC encoding so that LDP peers are able to setup an MP LSP via
their own defined MTR policy. In order to avoid conflicting MTR
policies for the same mLDP FEC, the MT-ID needs to be a part of the
FEC, so that different MT-ID values will result in unique MP-LSP FEC
elements.
Since the MT-ID is part of the FEC, it will apply to all the LDP
messages that potentially include an mLDP FEC element.
4.1. MP FEC Extensions for MT
Following subsections propose the extensions to bind an mLDP FEC to
a topology. The mLDP MT extensions reuse some of the extensions
specified in [MT-LDP].
4.1.1. MP FEC Element
Base mLDP specification [RFC6388] defines MP FEC Element as follows:
Wijnands, et. al Expires December 2013 [Page 4]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MP FEC Element Format [RFC6388]
Where "Root Node Address" encoding is as defined for given "Address
Family", and whose length (in octets) is specified by the "AF
Length" field.
To extend MP FEC elements for MT, the MT-ID is an identifier that is
relevant in the context of the root address of the MP LSP. The MT-ID
identifier determines in which topology the root address needs to be
resolved. Since the MT-ID should be considered part of the mLDP FEC,
the most natural place to encode the MT-ID is as part of the root
address. To encode MT-ID as part of the root address, we are
proposing to use "MT IP" Address Families as described in following
sub section.
4.1.2. MT IP Address Families
[MT-LDP] specification proposes new address families, named "MT IP"
and "MT IPv6", to allow specification of an IP prefix within a
topology scope. The Figure 2 of [MT-LDP] specification defines the
format of the data associated with these new Address Families 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (IP) Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MT IP Address Families Data Format [MT-LDP]
Wijnands, et. al Expires December 2013 [Page 5]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
Where "(IP) Prefix" is an IPv4 or IPv6 address corresponding to "MT
IP" and "MT IPv6" address families respectively.
4.1.3. MT MP FEC Element
We extend MP FEC Element for MT by using MT IP Address Family (and
its associated MT-ID) in an MP FEC Element. The resultant MT MP FEC
element will be encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IP MT-Scoped MP FEC Element Format
In the context of this document, the applicable LDP FECs for MT mLDP
include:
o MP FEC Elements:
o P2MP (type 0x6)
o MP2MP-up (type 0x7)
o MP2MP-down (type 0x8)
o Typed Wildcard FEC Element (type 0x5)
In case of "Typed Wildcard FEC Element", the sub FEC Element type
MUST be one of the MP FECs listed above.
This specification allows the use of Topology-scoped mLDP FECs in
LDP label and notification messages, as applicable.
Wijnands, et. al Expires December 2013 [Page 6]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
4.2. Topology IDs
This document assumes the same definitions and procedures associated
with MT-ID as defined in [MT-LDP] specification.
5. MT Multipoint Capability
"MT Multipoint Capability" is a new LDP capability, defined in
accordance with LDP Capability definition guidelines [RFC5561], that
is to be advertised to its peers by an mLDP speaker to announce its
capability to support MTR and the procedures specified in this
document. This capability MAY be sent either in an Initialization
message at the session establishment time, or in a Capability
message dynamically during the lifetime of a session (only if
"Dynamic Announcement" capability [RFC5561] has been successfully
negotiated with the peer).
The format of this capability 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| MT Multipoint Cap.(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 4: "MT Multipoint Capability" TLV Format
Where:
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
LDP Capabilities [RFC5561].
MT Multipoint Capaility: TLV type (IANA assigned).
Length: The length (in octets) of TLV. The value of this field
MUST be 1 as there is no Capability-specific data [RFC5561]
that follows in the TLV.
S-bit: Set to 1 to announce and 0 to withdraw the capability (as
per [RFC5561]).
An mLDP speaker that has successfully advertised and negotiated "MT
Multipoint" capability MUST support the following:
Wijnands, et. al Expires December 2013 [Page 7]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
1. Topology-scoped mLDP FECs in LDP messages ( Section 4.1. )
2. Topology-scoped mLDP forwarding setup ( Section 7. )
6. MT Applicability on FEC-based features
6.1. Typed Wildcard MP FEC Elements
[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 for a given type of FEC.
The MT extensions proposed in document do not require any extension
in procedures for Typed Wildcard FEC Element support [RFC5918], and
these procedures apply as-is to Multipoint MT FEC wildcarding. Like
Typed Wildcard MT Prefix FEC Element, as defined in [MT-LDP], the MT
extensions allow use of "MT IP" or "MT IPv6" in the Address Family
field of the Typed Wildcard MP FEC element in order to use wildcard
operations for MP FECs in the context of a given topology as
identified by the MT-ID field.
This document proposes following format and encoding for a Typed
Wildcard MP FEC element:
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)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT ID (contd.) |
+-+-+-+-+-+-+-+-+
Figure 5: "Typed Wildcard MT MP FEC Element"
Where:
Type: One of MP FEC Element type (P2MP, MP2MPup, MP2MP-down).
The proposed format allows an LSR to perform wildcard MP FEC
operations under the scope of a topology.
6.2. End-of-LIB
[RFC5919] specifies extensions and procedures that allows an LDP
speaker to signal its End-of-LIB (i.e. convergence) for a given FEC
Wijnands, et. al Expires December 2013 [Page 8]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
type towards a peer. MT extensions for MP FEC do not require any
change in these procedures and they apply as-is to MT MP FEC
elements. This means that an MT mLDP speaker MAY signal its
convergence per topology using MT Typed Wildcard MP FEC element.
7. Topology-Scoped Forwarding
Since the MT-ID is part of an mLDP FEC, there is no need to support
the concept of multiple topology tables in mLDP. Each MP LSP will be
unique due to the MT-ID being part of the FEC. There is also no need
to have specific label forwarding tables per topology, and each MP
LSP will have its own unique local label in the table. However, In
order to implement MTR in an mLDP network, the selection procedures
for upstream LSR and downstream forwarding interface need be
changed.
7.1. Upstream LSR selection
The procedures as described in RFC-6388 section-2.4.1.1 depend on
the best path to reach the root. When the MT-ID is signaled as part
of the FEC, the MT-ID is used to select the topology that must be
used to find the best path to the root address. Using the next-hop
from this best path, a LDP peer is selected following the procedures
as defined in [RFC6388].
7.2. Downstream forwarding interface selection
The procedures as described in RFC-6388 section-2.4.1.2 describe how
a downstream forwarding interface is selected. In these procedures,
any interface leading to the downstream LDP neighbor can be
considered as candidate forwarding interface. When the MT-ID is part
of the FEC, this is no longer true. An interface must only be
selected if it is part of the same topology that was signaled in the
mLDP FEC element. Besides this restriction, the other procedures in
[RFC6388] apply.
8. LSP Ping Extensions
[RFC6425] defines procedures to detect data plane failures in
Multipoint MPLS LSPs. Section 3.1.2 of [RFC6425] defines new Sub-
Types and Sub-TLVs for Multipoint LDP FECs to be sent in "Target FEC
Stack" TLV of an MPLS echo request message [RFC4379].
To support LSP ping for MT Multipoint LSPs, this document uses
existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
defined in [RFC6425]. The proposed extension is to specify "MT IP"
or "MT IPv6" in the "Address Family" field, set the "Address Length"
Wijnands, et. al Expires December 2013 [Page 9]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV
with additional MT-ID information as an extension to the "Root LSR
Address" field. The resultant format of sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multipoint LDP FEC Stack Sub-TLV Format for MT
The rules and procedures of using this new sub-TLV in an MPLS echo
request message are same as defined for P2MP/MP2MP LDP FEC Stack
Sub-TLV in [RFC6425] with only difference being that Root LSR
address is now topology scoped.
9. Security Considerations
This extension to mLDP does not introduce any new security
considerations beyond that already apply to the base LDP
specification [RFC5036], base mLDP specification [RFC6388], and MPLS
security framework [RFC5920].
10. IANA Considerations
This document defines a new LDP capability parameter TLV. IANA is
requested to assign the lowest available value after 0x0500 from
"TLV Type Name Space" in the "Label Distribution Protocol (LDP)
Parameters" registry within "Label Distribution Protocol (LDP) Name
Spaces" as the new code point for the LDP TLV code point.
Wijnands, et. al Expires December 2013 [Page 10]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
+-----+------------------+---------------+-------------------------+
|Value| Description | Reference | Notes/Registration Date |
+-----+------------------+---------------+-------------------------+
| TBA | MT Multipoint | This document | |
| | Capability | | |
+-----+------------------+---------------+-------------------------+
11. References
11.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-
Esnault, "Multi-Topology Routing in OSPF", RFC 4915, June
2007.
[RFC5120] T. Przygienda, Z2 Sagl, N. Shen, N. Sheth, "M-ISIS: Multi-
Topology Routing in IS-IS", RFC 5120, February 2008.
[MT-LDP] Q. Zhao, L. Fang, C. Zhou, L. Li, K. Raza, "LDP Extensions
for Multiple Topology Routing", draft-ietf-mpls-ldp-multi-
topology-08, Work in progress, May 2013.
[RFC6388] I. Minei, I. Wijnands, K. Kompella, B. Thomas,
"LDP Extensions for P2MP and MP2MP LSPs", RFC 6388,
November 2011.
[RFC4379] S. Sexana, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
T. Nadeau, "Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures", RFC 4379, February 2006.
[RFC6425] Kompella, K. and G. Swallow, "Detecting Data-Plane Failures
in Point-to-Multipoint MPLS - Extensions to LSP Ping",
RFC 6425, November 2011.
11.2. Informative References
[RFC5036] L. Andersson, I. Minei, B. Thomas, "LDP Specification",
RFC 5036, October 2007.
[RFC5919] R. Asati, P. Mohapatra, E. Chen, B. Thomas, "Signaling LDP
Label Advertisement Completion", RFC 5919, August 2010.
[RFC5918] R. Asati, I. Minei, B. Thomas, "Label Distribution
Protocol Typed Wildcard FEC", RFC 5918, August 2010.
Wijnands, et. al Expires December 2013 [Page 11]
Internet-Draft mLDP Extensions for Multi-Topology Routing June 2013
[RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux,
"LDP Capabilities", RFC 5561, July 2009.
12. Acknowledgments
The authors would like to acknowledge Eric Rosen for his input on
this specification.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a,
Diegem 1831 Belgium.
Email: ice@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive,
Kanata, Ontario K2K-3E8, Canada.
Email: skraza@cisco.com
Wijnands, et. al Expires December 2013 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-21 23:21:08 |