Internet Engineering Task Force Quintin Zhao
Internet-Draft Huawei Technology
Intended status: Standards Track Chao Zhou
Expires: September 13, 2011 Luyuan Fang
Cisco Systems
Lianyuan Li
China Mobile
Ning So
Verison Business
Raveendra Torvi
Juniper Networks
March 12, 2011
RSVP-TE Extension for Multi Topology Support
draft-zhao-mpls-rsvp-te-multi-topology-01.txt
Abstract
This document describes options to extend the existing MPLS
signalling protocol RSVP for creating and maintaining Label Switching
Paths (LSPs) in a Multi-Topology environments.
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
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 September 13, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhao, et al. Expires September 13, 2011 [Page 1]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
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.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 5
3.2. Automation of inter-layer interworking . . . . . . . . . . 5
3.3. Migration without service disruption . . . . . . . . . . . 6
3.4. Service Separation . . . . . . . . . . . . . . . . . . . . 6
3.5. simplified Inter Domain TE LSP Setup . . . . . . . . . . . 6
3.6. Simplified inter-AS VPN Solution . . . . . . . . . . . . . 6
4. Associating a RSVP message with MT-ID . . . . . . . . . . . . 7
4.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 7
4.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 8
4.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 10
4.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 11
5. Processing of Message with MT ID . . . . . . . . . . . . . . . 11
6. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 11
6.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 11
6.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 12
7. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 13
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhao, et al. Expires September 13, 2011 [Page 2]
Internet-Draft RSVP-TE Multi Topology Extension March 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.
2. Introduction
In Multi-protocol Label Switching (MPLS) networks, a label may be
assigned to represent a set of Forwarding Equivalent Classes (FEC) of
packets and a mapping of the label and the FEC may be signaled along
the path traversed by the packets. Therefore, the label switched
paths are established to forward packets.
Resource reservation protocol (RSVP) is a network control protocol
that may be used to enable applications to obtain different quality
of service (QoS) for their data flows. However, RSVP is not a
routing protocol. Rather, RSVP operates in conjunction with routing
protocols.
Resource reservation protocol traffic engineering (RSVP-TE) is an
extension to RSVP that supports resource reservations across an
Internet Protocol (IP) network. Generally, RSVP-TE may be used to
establish MPLS label switched paths (LSPs) with or without resource
reservations, with consideration given to available bandwidth and a
number of explicit hops. The LSPs may be setup using explicit
routes. A variety of messages and procedures may be used by network
elements to inform other network elements of the labels used for MPLS
forwarding. The LSPs may be treated as a tunnel, which is tunneling
below normal IP routing and filtering mechanisms.
A mechanism for Open Shortest Path First (OSPF) protocol to support
multi-topologies (MT) in IP networks, wherein Type of Service (TOS)
based metric fields are redefined and used to advertise different
topologies is disclosed in P. Psenak, et.al., "Multi-Topology (MT)
Routing in OSPF," RFC 4915, June 2007, which is incorporated herein
by reference. Separate metrics may be associated for each TOS and
may be advertised via protocol information exchange between network
elements. The existing OSPF protocol is extended to support network
topology changes with Multi-Topology Identifier (MT-ID).
Zhao, et al. Expires September 13, 2011 [Page 3]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
A mechanism within Intermediate System to Intermediate System (IS-IS)
to run a set of independent IP topologies for each network topology
is disclosed in T. Przygienda, et.al., "M-ISIS: Multi Topology (MT)
Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC
5120, February 2008, which is incorporated herein by reference. The
existing IS-IS protocol is extended so that advertisements of
adjacencies and reachable intermediate system within each topology
are performed.
Therefore, there is a need to have systems and methods for supporting
multi-topology in MPLS network and extending the RSVP-TE protocol as
a signaling protocol in the MPLS network to establish and maintain
traffic engineered LSP tunnel within each network topology or across
network topologies. The LSP tunnel may need to follow a specific
path or to reserve a certain amount of bandwidth to satisfy QoS
requirements for the traffic flowing through the LSP tunnel within a
specific network topology or across multiple network topologies.
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 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.
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 landline rather than, for example, high latency links such
as satellite links. As a result an additional topology is defined as
all low latency links on the network and VoIP data packets are
assigned 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
protocol (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 distinguished by the quality of service (QoS) assigned to it.
3. Application Scenarios
Zhao, et al. Expires September 13, 2011 [Page 4]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
3.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.2. Automation of inter-layer interworking
With (G)MPLS-RSVP-MT extensions, an ingress-PE can signal particular
path (ERO) that can traverses different network layer to reach a
egress-PE. For instance, an ERO is associated with MT-ID RSVP
subobject to indicate a "P" router to use a particular Layer-1 TE-
link-state topology, instead of default Layer-3 link-state topology
as illustrated in the following diagram. With this mechanism an
(G)MPLS-TE LSP can be offloaded to lower layers without service
disruption and without complexity of configuration.
+-------+ +-------+
+---------+ R3 .__________ | R4 +------.
| +-------+ +-------+ |
+-------+ +--+---+ +-'---+
| I-PE |_.| P | |E-PE |
| | +--+---+ +-.---+
+-------+ | |
| +---------+ +-------+ |
|_______| S1 |_____| S2 |____________|
+---------+ +-------+
Figure 1: Layer-3 Link State Topology
Layer-3 ERO : P[MT-0]->R3->R4->E-PE[MT-0].
Inter-layer ERO : P[MT-0]->loose-hop[MT-1]->E-PE[MT-0]
Procedures to discover MT mapping with an IGP topology at ingress-PE
Zhao, et al. Expires September 13, 2011 [Page 5]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
nodes requires some auto-discovery mechanism.
Figure 1: Layer-3 Link State Topology
3.3. Migration without service disruption
As state above, MPLS-MT abstracts link state topology and identifies
it by a unique MT-ID, which need not be same as IGP-MT ID. This
characteristic is quite useful for service providers looking to
migrate to different flavor of IGP, e.g., OSPFv2 to ISIS6, OSPFv2 to
OSPFv3. Service providers would like to incrementally upgrade the
topologies, which requires an LSP to traverse multiple IGP domains
(OSPFv2 to OSPFv3) or (OSPF to ISIS). In order migrate TE-LSPs to
use newly deployed link state topology requires a non-trivial effort.
This migration may involve service disruption, especially when a path
include loose-hops in the ERO. For example: When an incoming PATH
message requires an LSR to resolve loose-hop over newly deployed IGP
domain, which is not possible in the absence of MPLS-MT signaling.
MPLS-MT allows an ingress-PE to specify multi-topology to be used at
every hop.
3.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.5. simplified Inter Domain TE LSP Setup
When the TE lsp is crossing multiple domains, the LSP setup process
can be simplified by configuring a set of routers which are in
different domains into a new single domain with a new toplogy ID
using the RSVP-TE multiple topology. All the routers belong this new
topology will be used to carry the traffic acrossing multiple domains
and since they are in a sinle domain, so the TE lsp set up can be
done easily.
3.6. Simplified inter-AS VPN Solution
When the TE lsp is crossing multiple domains for the inter-as VPN
scenarios, the LSP setup process can be simplified by configuring a
set of routers which are in different domains into a new single
domain with a new toplogy ID using the LDP multiple topology. All
Zhao, et al. Expires September 13, 2011 [Page 6]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
the routers belong this new topology will be used to carry the
traffic acrossing multiple domains and since they are in a sinle
domain with the new topology ID, so the TE lsp set up can be done
easily without the complex inter-as VPN solution's option A, option B
and option C.
4. Associating a RSVP message with MT-ID
RSVP-TE objects may be utilized to indicate MT information by adding
the multi-topology information in an RSVP-TE object carried in a
RSVP-TE message.
A preferred RSVP-TE object may be a session object.
The capability for supporting multi-topology in RSVP can be
advertised during RSVP session initialization stage by including the
extended RSVP session object in the first RSVP path message. After
RSVP session is established, the following Path, Resv, PathErr,
ResvErr and ResvConf messages will include the session object in each
message and the MT ID contained in the session object will let the
receiver of the message to know which topology this message is for.
This section describes an approach to associate a RSVP message with
MT-ID specified in the session object.
4.1. Session Object
4.1.1. P2P LSP TUNNEL IPv4 Session Object
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv(0)| MT-ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of P2P LSP_TUNNEL_IPv4 Session Object Body with
MT-ID
Zhao, et al. Expires September 13, 2011 [Page 7]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
IPv4 tunnel end point address
IPv4 address of the egress node for the tunnel.
MT-ID
A 12 bit value to represent Multi-Topology Identifier.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
Extended Tunnel ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv4 address here as a
globally unique identifier.
4.1.2. P2P LSP TUNNEL IPv6 Session Object
This is the same as the P2MP IPv4 LSP SESSION object with the
difference that the extended tunnel ID may be set to a 16-byte
identifier [RFC3209].
Zhao, et al. Expires September 13, 2011 [Page 8]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv(0)| MT-ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of P2P LSP_TUNNEL_IPv6 Session Object Body with
MT-ID
IPv6 tunnel end point address
IPv6 address of the egress node for the tunnel.
MT-ID
A 12 bit value to represent a Multi-Topology Identifier.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
Extended Tunnel ID
A 16-byte identifier used in the SESSION that remains constant
over the life of the tunnel. Normally set to all zeros.
Ingress nodes that wish to narrow the scope of a SESSION to the
ingress-egress pair may place their IPv6 address here as a
globally unique identifier.
Zhao, et al. Expires September 13, 2011 [Page 9]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
4.1.3. P2MP LSP TUNNEL IPv4 Session Object
This is the same as the P2MP IPv4 LSP SESSION object with the
difference that the extended tunnel ID may be set to a 16-byte
identifier [RFC3209].
Class = SESSION, P2MP_LSP_TUNNEL_IPv4 C-Type = 13
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv(0)| MT-ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP ID
A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. It encodes the P2MP
Identifier that is unique within the scope of the ingress LSR.
MT-ID
A 12 bit value to represent a Multi-Topology Identifier.
Tunnel ID
A 16-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel.
Extended Tunnel ID
A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP tunnel. Ingress LSRs that wish
to have a globally unique identifier for the P2MP tunnel SHOULD
place their tunnel sender address here. A combination of this
address, P2MP ID, and Tunnel ID provides a globally unique
identifier for the P2MP tunnel.
Figure 4: Format of P2MP LSP_TUNNEL_IPv4 Session Object Body with
MT-ID
Zhao, et al. Expires September 13, 2011 [Page 10]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
4.1.4. P2MP LSP TUNNEL IPv6 Session Object
Class = SESSION, P2MP_LSP_TUNNEL_IPv6 C-Type = 14
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv(0)| MT-ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of P2MP LSP_TUNNEL_IPv6 Session Object Body with
MT-ID
5. Processing of Message with MT ID
Procedure changes for processing P2P and P2MP protocol messages with
MT ID: [TBD]
6. MPLS Forwarding in MT
In MT based MPLS network, forwarding will not only be based on label,
but also based on the MT-ID associated with the label. There are
multiple options to do this. Below, we list three options.
6.1. Use Label for (FEC, MT-ID) Tuple
The first option we propose is that MPLS forwarding for different
topologies is implied by labels. This approach does not need any
changes to the exiting MPLS hardware forwarding mechanism. It also
resolves the forwarding issue that exists in IGP multi-topology
forwarding when multiple topologies share an interface with
overlaying addresses.
On a MT aware LSR, each label is associated with tuple: (FEC, MT-ID).
Therefore, same FEC with different MT-ID would be assigned to
different labels.
Using this option, for tuple (FEC-F, MT-ID-N1) and (FEC-F, MT-ID-N2),
Zhao, et al. Expires September 13, 2011 [Page 11]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
each LSR along the path that is shared by topology MT-ID-N1 and MT-
ID-N2 will allocate different labels to them. Thus two distinguished
Label Switching Paths will be created. One (FEC-F, MT-ID-N1) and the
other for (FEC-F, MT-ID-N1). The traffic for them will follow
different Label Switching Paths (LSPs).
Note, in this option, label space is not allowed to be overlapping
among different MTs. In the above example, each label belongs to a
specific topology or the default topology. MPLS forwarding will be
performed exactly same as non-MT MPLS forwarding: using label to find
output information. This option will not require any change of
hardware forwarding to commodate MPLS MT.
Note, We have different RIBs corresponding to different MT IDs. But
we will only need one LFIB.
Below is an example for option one:
RIB(x) for MT-IDx:
FEC NEXT HOP
FECi(Destination A) R1
RIB(y) for MT-IDy:
FEC NEXT HOP
FECi(Destination A) R1
LFIB:
Ingress Label Egress Label NEXT HOP
Lm Lp R1
Ln Lq R2 (could be same as R1)
Figure 6: FIB Entry Example for One Label Space
6.2. Overlapping Label Spaces for MT
In the option 2, label spaces are overlapping with each other, which
means same label value could be used for different MT. In this
option, MPLS forwarding will use label value and the MT associated
with label. Each label forwarding entry will have an extra label
stacked with the original label. This extra label is used as the MT
identifier. For example, the forwarding entry in the LIB looks like
this:
Zhao, et al. Expires September 13, 2011 [Page 12]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | MT identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FIB Entry of Overlapping Label Spaces for MT
Option 1 is good for backward compatibility and it doesn't require
hardware change. The disadvantage is that the 20 bits of label space
is shared by all the MTs and label space for each MT is limited. The
advantage for option 2 is that each MT can have full label space.
The disadvantage is that they need hardware support to perform MPLS
MT forwarding. In addition, option 2 require one more label lookup.
7. Reserved MT ID Values
Certain MT topologies are assigned to serve pre-determined purposes:
[TBD]
8. 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.
9. IANA Considerations
TBD
10. Acknowledgement
The authors would like to thank Dan Tappan, Nabil Bitar and Huang Xin
for their valuable comments on this draft.
11. References
Zhao, et al. Expires September 13, 2011 [Page 13]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
11.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.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007.
[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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment
Using Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
11.2. Informative References
Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
Zhao, et al. Expires September 13, 2011 [Page 14]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
Huaimo Chen
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: huaimochen@huawei.com
Ning So
Verison Business
2400 North Glenville Drive
Richardson, TX 75082
USA
Email: Ning.So@verizonbusiness.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
Lianyuan Li
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lilianyuan@chinamobile.com
Zhao, et al. Expires September 13, 2011 [Page 15]
Internet-Draft RSVP-TE Multi Topology Extension March 2011
Lu Huang
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: huanglu@chinamobile.com
Chen Li
China Mobile
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lichenyj@chinamobile.com
Raveendra Torvi
Juniper Networks
10, Technoogy Park Drive
Westford, MA 01886-3140
US
Email: pratiravi@juniper.com
Zhao, et al. Expires September 13, 2011 [Page 16]