Internet Engineering Task Force Q. Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track L. Fang
Expires: May 3, 2012 C. Zhou
Cisco Systems
L. Li
China Mobile
N. So
Verizon Business
R. Torvi
Juniper Networks
October 31, 2011
LDP Extensions for Multi Topology Routing
draft-ietf-mpls-ldp-multi-topology-01.txt
Abstract
Multi-Topology (MT) routing is supported in IP through extension of
IGP protocols, such as OSPF and IS-IS. It would be advantageous to
extend Multiprotocol Label Switching (MPLS), using Label Distribution
Protocol (LDP), to support multiple topologies. These LDP
extensions, known as Multiple Topology Label Distribution Protocol
(MT LDP), would allow the configuration of multiple topologies within
an MPLS LDP enabled network.
This document describes the protocol extensions required to extend
the existing MPLS LDP signalling protocol for creating and
maintaining LSPs in an MT environment.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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
Zhao, et al. Expires May 3, 2012 [Page 1]
Internet-Draft LDP Multi Topology Extension October 2011
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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhao, et al. Expires May 3, 2012 [Page 2]
Internet-Draft LDP Multi Topology Extension October 2011
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 6
3.1.1. Simplified Data-plane . . . . . . . . . . . . . . . . 6
3.1.2. Using MT for p2p Protection . . . . . . . . . . . . . 6
3.1.3. Using MT for mLDP Protection . . . . . . . . . . . . . 7
3.1.4. Service Separation . . . . . . . . . . . . . . . . . . 7
3.1.5. An Alternative inter-AS VPN Solution . . . . . . . . . 7
3.2. Associating a FEC or group of FECs with MT-ID . . . . . . 8
3.2.1. MT-ID TLV . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. FEC TLV with MT-ID Extension . . . . . . . . . . . . . 9
3.3. LDP MT Capability Advertisement . . . . . . . . . . . . . 9
3.3.1. Session Initialization . . . . . . . . . . . . . . . . 10
3.3.2. Post Session Setup . . . . . . . . . . . . . . . . . . 11
3.4. LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Reserved MT ID Values . . . . . . . . . . . . . . . . . . 12
3.6. LDP Messages with FEC TLV and MT-ID TLV . . . . . . . . . 12
3.6.1. Label Mapping Message . . . . . . . . . . . . . . . . 13
3.6.2. Label Request Message . . . . . . . . . . . . . . . . 14
3.6.3. Label Abort Request Message . . . . . . . . . . . . . 14
3.6.4. Label Withdraw Message . . . . . . . . . . . . . . . . 15
3.6.5. Label Release Message . . . . . . . . . . . . . . . . 16
3.7. Session Initialization Message with MT Capability . . . . 16
3.8. MT Applicability on FEC-based features . . . . . . . . . . 17
3.8.1. Typed Wildcard Prefix FEC Element . . . . . . . . . . 17
3.8.2. End-of-LIB . . . . . . . . . . . . . . . . . . . . . . 17
3.9. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . 18
3.10. Security Consideration . . . . . . . . . . . . . . . . . . 18
3.11. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
3.12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . 18
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Normative References . . . . . . . . . . . . . . . . . . . 18
4.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Zhao, et al. Expires May 3, 2012 [Page 3]
Internet-Draft LDP Multi Topology Extension October 2011
1. Terminology
Terminology used in this document
MT-ID: A 12 bit value to represent Multi-Topology ID.
Default Topology: A topology that is built using the MT-ID value
0.
MT topology: A topology that is built using the corresponding
MT-ID.
1.1. 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].
2. Introduction
There are increasing requirements to support multi-topology in MPLS
network. For example, service providers may want to assign different
level of service(s) to different topologies so that the service
separation can be achieved. It is also possible to have an in-band
management network on top of the original MPLS topology, or maintain
separate routing and MPLS domains for isolated multicast or IPv6
islands within the backbone, or force a subset of an address space to
follow a different MPLS topology for the purpose of security, QoS or
simplified management and/or operations.
OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify
different topologies. For each topology identified by a MT-ID, IGP
computes a separate SPF tree independently to find the best paths to
the IP prefixes associated with this topology.
For FECs that are associated with a specific topology, this solution
utilises the same MT-ID of this topology in LDP. Thus LSP for a
certain FEC may be created and maintained along the IGP path in this
topology.
Maintaining multiple MTs for MPLS network in a backwards-compatible
manner requires several extensions to the label signaling encoding
and processing procedures. When label is associated with a FEC, the
FEC includes both IP address and topology it belongs to.
There are a few possible ways to apply the MT-ID of a topology in
LDP. One way is to have a new TLV for MT-ID and insert the TLV into
Zhao, et al. Expires May 3, 2012 [Page 4]
Internet-Draft LDP Multi Topology Extension October 2011
messages describing a FEC that needs Multi-Topology information.
Another approach is to expand the FEC TLV to contain MT-ID if the FEC
needs Multi-Topology information.
MT based MPLS in general can be used for a variety of purposes such
as service separation by assigning each service or a group of
services to a topology, where the managment, QoS and security of the
service or the group of the services can be simplified and
guaranteed, in-band management network "on top" of the original MPLS
topology, maintain separate routing and MPLS forwrding domains for
isolated multicast or IPv6 islands within the backbone, or force a
subset of an address space to follow a different MPLS topology for
the purpose of security, QoS or simplified management and/or
operations.
One of the use of the MT based MPLS is where one class of data
requires low latency links, for example Voice over Internet Protocol
(VoIP) data. As a result such data may be sent preferably via
physical landlines rather than, for example, high latency links such
as satellite links. As a result an additional tolology is defined as
all low latency links on the network and VoIP data packets are
assinged to the additional topology. Another example is security-
critical traffic which may be assigned to an additional topology for
non-radiative links. Further possible examples are file transfer
prtocol (FTP) or SMTP (simple mail transfer protocol) traffic which
can be assigned to additional topology comprising high latency links,
Internet Protocol version 4 (IPv4) versus Internet Protocol version 6
(IPv6) traffic which may be assigned to different topology or data to
be distingushed by the quality of service (QoS) assinged to it.
This document describes the protocol extensions required to extend
the existing MPLS LDP signalling protocol for creating and
maintaining LSPs in an MT environment.
3. Requirements
MPLS-MT may be used for a variety of purposes such as service
separation by assigning each service or a group of services to a
topology, where the management, QoS and security of the service or
the group of the services can be simplified and guaranteed, in-band
management network "on top" of the original MPLS topology, maintain
separate routing and MPLS forwarding domains for isolated multicast
or IPv6 islands within the backbone, or force a subset of an address
space to follow a different MPLS topology for the purpose of
security, QoS or simplified management and/or operations.
The following specific requirements and objectives have been defined
Zhao, et al. Expires May 3, 2012 [Page 5]
Internet-Draft LDP Multi Topology Extension October 2011
in order to provide the functionality described above, and facilitate
service provider configuration and operation.
o Deployment of MPLS-MT within existing MPLS networks should be
possible, with MPLS-MT non-capable nodes existing with MPLS-MT
capable nodes.
o Minimise configuration and operation complexity of MPLS-MT across
the network.
o The MPLS-MT solution SHOULD NOT require data-plane modification.
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.
[Editors Note - We expect these base MPLS-MT protocol requirements to
be evolved over the next few versions of this document. Note that
all Editors notes will be deleted before publication of the document]
3.1. Application Scenarios
3.1.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.
3.1.2. Using MT for p2p Protection
We know that [IP-FRR-MT] can be used for configuring alternate path
via backup-mt, such that if primary link fails, then backup-MT can be
used for forwarding. However, such techniques require special
Zhao, et al. Expires May 3, 2012 [Page 6]
Internet-Draft LDP Multi Topology Extension October 2011
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.
3.1.3. Using MT for mLDP Protection
Fro 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
priamry LSP in the appplicaitons such 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
guranteed 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 independantly within each topology. The two LSPs setup by
this mechanism can protect each other end-to-end.
3.1.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 CoS 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.
3.1.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 May 3, 2012 [Page 7]
Internet-Draft LDP Multi Topology Extension October 2011
3.2. Associating a FEC or group of FECs with MT-ID
This section describes multiple approaches to associate a FEC or a group
of FECs to a MT-ID in LDP. One way is to have a new TLV for MT-ID
and insert the MT-ID TLV into messages describing a FEC that needs
Multi-Topology information. Another approach is to extend FEC TLV to
contain the MT-ID if the FEC needs Multi-Topology information. There are
also other choices such as defining new address family or associate the
MPLS MT-ID with each FEC element in the FEC TLV. In this version, we discuss
the first two choices, and in the future versions, we will add the discussions
for other choices into the draft.
3.2.1. MT-ID TLV
The new TLV for MT-ID is defined as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
U and F bits:
As specified in [RFC5036].
TLV Code Point:
The TLV type which identifies a specific capability.
MT-ID is a 12-bit field containing the ID of the topology
corresponding to the MT-ID used in IGP and LDP. Lack of MT-ID TLV
in messages MUST be interpreted as FECs are used in default
MT-ID (0) only.
A MT-ID TLV can be inserted into the following LDP messages as
an optional parameter.
Label Mapping "Label Mapping Message"
Label Request "Label Request Message"
Label Abort Request "Label Abort Request Message"
Label Withdraw "Label Withdraw Message"
Label Release "Label Release Message"
The message with inserted MT-ID TLV associates a FEC in same message
to the topology identified by MT-ID.
Figure 1: MT-ID TLV Format
Zhao, et al. Expires May 3, 2012 [Page 8]
Internet-Draft LDP Multi Topology Extension October 2011
3.2.2. FEC TLV with MT-ID Extension
The new TLV for MT-ID is defined as below:
The extended FEC TLV has the format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| FEC (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This new FEC TLV may contain a number of FEC elements and a MT-ID.
It associates these FEC elements with the topology identified by
the MT-ID. Each FEC TLV can contain only one MT-ID.
Figure 2: Extended FEC with MT-ID
3.3. LDP MT Capability Advertisement
The LDP MT capability can be advertised either during the LDP session
initializatin or after the LDP session is setup.
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 LDP session is
established, the MT capability can also be advertised or changed
using Capability message.
If an LSR has not advertised MT capability, its peer must not send
messages that include MT identifier to this LSR.
If an LSR receives a Label Mapping message with MT parameter from
downstream LSR-D and its upstream LSR-U has not advertised MT
Zhao, et al. Expires May 3, 2012 [Page 9]
Internet-Draft LDP Multi Topology Extension October 2011
capability, an LSP for the MT will not be established.
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).
If an LSR is changed from MT capable to non-MT capable, it may
initiate withdraw of all label mapping for existing LSPs of all non-
default MTs. Alternatively, it may wait until the routing update to
withdraw FEC and release the label mapping for existing LSPs of
specific MT.
There will be case where IGP is MT capable but MPLS is not and the
handling procedure for this case is TBD.
3.3.1. Session Initialization
In an LDP session initialization, the MT capability may be advertised
through an extended session initialization message. This extended
message has the same format as the original session initialization
message but contains the LDP MT capability TLV as an optional
parameter.
The format of the TLV for LDP MT is specified in the [RFC5036] as
below:
Zhao, et al. Expires May 3, 2012 [Page 10]
Internet-Draft LDP Multi Topology Extension October 2011
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| TLV Code Point(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
U and F bits:
As specified in [RFC5036].
TLV Code Point:
The TLV type which identifies a specific capability. The "IANA
Considerations" section of [RFC5036] specifies the assignment of
code points for LDP TLVs.
S-bit:
The State Bit indicates whether the sender is advertising or
withdrawing the capability corresponding to the TLV Code Point.
The State bit is used as follows:
1 - The TLV is advertising the capability specified by the
TLV Code Point.
0 - The TLV is withdrawing the capability specified by the
TLV Code Point.
Capability Data:
Information, if any, about the capability in addition to the TLV
Code Point required to fully specify the capability.
Figure 3: LDP MT CAP TLV
3.3.2. Post Session Setup
During the normal operating stage of LDP sessions, the capability
message defined in the [RFC5036] will be used with an LDP MT
capability TLV.
The format of the Capability message is as follows:
Zhao, et al. Expires May 3, 2012 [Page 11]
Internet-Draft LDP Multi Topology Extension October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Capability (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_1 (LDP-MT Capability TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LDP CAP Format
where TLV_1 (LDP-MT Capability TLV) specifies that the LDP MT
capability is enabled or disabled by setting the S bit of the TLV to
1 or 0.
3.4. 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.
[Editors Note - This section requires further discussion]
3.5. Reserved MT ID Values
Certain MT topologies are assigned to serve pre-determined purposes:
[Editors Note - This section requires further discussion]
3.6. LDP Messages with FEC TLV and MT-ID TLV
Zhao, et al. Expires May 3, 2012 [Page 12]
Internet-Draft LDP Multi Topology Extension October 2011
3.6.1. Label Mapping Message
An LSR sends a Label Mapping message to an LDP peer to advertise FEC-
label bindings. In the Optional Parameters' field, the MT-ID TLV
will be inserted.
The encoding for the Label Mapping message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are:
Optional Parameter Length Value
Label Request 4 See below
Message ID TLV
Hop Count TLV 1 See below
Path Vector TLV variable See below
MT TLV variable See below
MT TLV
see the definition section for this new TLV.
Figure 5: Label Mapping Message
Zhao, et al. Expires May 3, 2012 [Page 13]
Internet-Draft LDP Multi Topology Extension October 2011
3.6.2. Label Request Message
An LSR sends the Label Request message to an LDP peer to request a
binding (mapping) for a FEC. The MT TLV will be inserted into the
Optional parameters' field.
The encoding for the Label Request message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Label Request Message
In the DU mode, when a label mapping is received by a LSR which has a
downstream with MT capability advertised and an upstream without the
MT capability advertised, it will not send label mapping to its
upstream.
in the DoD mode, the label request is sent down to the downstream LSR
until it finds the downstream LSR which doesn't support the MT, then
the current LSPR will send a notification to its upstream LSR. In
this case, no LSP is setup.
We propose to add a new notification event to signal the upstream
that the downstream is not capable.
3.6.3. Label Abort Request Message
The Label Abort Request message may be used to abort an outstanding
Label Request message. The MT TLV may be inserted into the optional
parameters' field.
The encoding for the Label Abort Request message is:
Zhao, et al. Expires May 3, 2012 [Page 14]
Internet-Draft LDP Multi Topology Extension October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Abort Req (0x0404) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Label Abort Request Message
3.6.4. Label Withdraw Message
An LSR sends a Label Withdraw Message to an LDP peer to signal the
peer that the peer may not continue to use specific FEC-label
mappings the LSR had previously advertised. This breaks the mapping
between the FECs and the labels. The MT TLV will be added into the
optional paramters field.
The encoding for the Label Withdraw Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Label Withdraw Message
Zhao, et al. Expires May 3, 2012 [Page 15]
Internet-Draft LDP Multi Topology Extension October 2011
3.6.5. Label Release Message
An LSR sends a Label Release message to an LDP peer to signal the
peer that the LSR no longer needs specific FEC-label mappings
previously requested of and/or advertised by the peer. The MT TLV
will be added into the optional paramers field.
The encoding for the Label Release Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Label Release Message
3.7. Session Initialization Message with MT Capability
The session initializtion message is extended to contain the LDP MT
capability as an optional parameter. The extended session
initialization message has the format below.
Zhao, et al. Expires May 3, 2012 [Page 16]
Internet-Draft LDP Multi Topology Extension October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP MT Capability TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Session Initialization Message with MT Capability
3.8. MT Applicability on FEC-based features
3.8.1. Typed Wildcard Prefix FEC Element
RFC-5918 extends base LDP and defines Typed Wildcard FEC Element
framework [RFC5918]. Typed Wildcard FEC element can be used in any
LDP message to specify a wildcard operation/action for given type of
FEC.
The impact of the MT extensions proposed in document on the
procedures for Typed Wildcard Prefix FEC element depends on the MPLS
MT-ID representation mechanism we chose at the end.
For example, if the MPLS-MT ID TLV option is the final choice, then
the procedures defined in [RFC5918] apply as-is to Prefix FEC element
or the Prefix FEC element along with the MPLS MT-ID TLV. For
instance, upon local un-configuration of topology "x", an LSR may
send wildcard label withdraw with MT-ID TLV "x" to withdraw all its
labels from peer that were advertised under the scope of topology
"x".
3.8.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 impact of the MT extensions proposed in document on the
procedures for End-of-LIB depends on the MPLS MT-ID representation
mechanism we chose at the end.
For example, if the MPLS-MT ID TLV option is the final choice, the
Zhao, et al. Expires May 3, 2012 [Page 17]
Internet-Draft LDP Multi Topology Extension October 2011
procedures defined in [RFC5919] apply as-is to Prefix FEC element or
the Prefix FEC element along with the MPLS MT-ID TLV. This means
that an LDP speaker MAY signal its IP convergence using Typed
Wildcard Prefix FEC element, and its MT IP convergence per topology
using the Typed Wildcard Prefix FEC element along with the MPLS MT-ID
TLV.
3.9. 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.
3.10. Security Consideration
MPLS security applies to the work presented. No specific security
issues with the proposed solutions are known. The authentication
procedure for RSVP signalling is the same regardless of MT
information inside the RSVP messages.
3.11. IANA Considerations
[Editors Note - This section requires further discussion]
3.12. Acknowledgement
The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin,
Daniel King and Eric Rosen for their valuable comments on this draft.
4. References
4.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
Zhao, et al. Expires May 3, 2012 [Page 18]
Internet-Draft LDP Multi Topology Extension October 2011
4.2. Informative References
Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintin.zhao@huawei.com
Huaimo Chen
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: huaimochen@huawei.com
Emily Chen
Huawei Technology
No. 5 Street, Shangdi Information, Haidian
Beijing
China
Email: chenying220@huawei.com
Lianyuan Li
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lilianyuan@chinamobile.com
Zhao, et al. Expires May 3, 2012 [Page 19]
Internet-Draft LDP Multi Topology Extension October 2011
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
Luyuang 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
Kamran Raza
Cisco Systems
2000 Innovation Drive
Kanata, ON K2K-3E8, MA
Canada
Email: E-mail: skraza@cisco.com
Zhao, et al. Expires May 3, 2012 [Page 20]
Internet-Draft LDP Multi Topology Extension October 2011
Ning So
Verizon Business
2400 North Glenville Drive
Richardson, TX 75082
USA
Email: Ning.So@verizonbusiness.com
Raveendra Torvi
Juniper Networks
10, Technoogy Park Drive
Westford, MA 01886-3140
US
Email: rtorvi@juniper.net
Zhao, et al. Expires May 3, 2012 [Page 21]
