Internet Engineering Task Force Quintin Zhao
Internet-Draft Huaimo Chen
Intended status: Standards Track Huawei Technology, Inc.
Expires: April 4, 2010 Luyuan Fang
Chao Zhou
Cisco Systems, Inc.
Lianyuan Li
Xin Huang
China Mobile, Inc.
October 19, 2009
RSVP Extesnion for Muti Topology Support
draft-zhao-rsvp-multi-topology-extension-00.txt
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), 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 April 4, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhao, et al. Expires April 4, 2010 [Page 1]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 enviroments.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Associating a RSVP message with MT-ID . . . . . . . . . . . . 4
3.1. Session Object . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. P2P LSP TUNNEL IPv4 Session Object . . . . . . . . . . 5
3.1.2. P2P LSP TUNNEL IPv6 Session Object . . . . . . . . . . 6
3.1.3. P2MP LSP TUNNEL IPv4 Session Object . . . . . . . . . 7
3.1.4. P2MP LSP TUNNEL IPv6 Session Object . . . . . . . . . 9
4. Processing of Message with MT ID . . . . . . . . . . . . . . . 9
5. MPLS Forwarding in MT . . . . . . . . . . . . . . . . . . . . 9
5.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 9
5.2. Overlapping Label Spaces for MT . . . . . . . . . . . . . 10
6. Reserved MT ID Values . . . . . . . . . . . . . . . . . . . . 11
7. Security Consideration . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhao, et al. Expires April 4, 2010 [Page 2]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 April 4, 2010 [Page 3]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 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.
3. Associating a RSVP message with MT-ID
RSVP-TE objects may be utilized to indicate MT information by adding
Zhao, et al. Expires April 4, 2010 [Page 4]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 inlcude 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.
3.1. Session Object
3.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 1: Format of P2P LSP_TUNNEL_IPv4 Session Object Body with
MT-ID
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
Zhao, et al. Expires April 4, 2010 [Page 5]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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.
3.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].
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 2: Format of P2P LSP_TUNNEL_IPv6 Session Object Body with
MT-ID
IPv6 tunnel end point address
Zhao, et al. Expires April 4, 2010 [Page 6]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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.
3.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].
Zhao, et al. Expires April 4, 2010 [Page 7]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 3: Format of P2MP LSP_TUNNEL_IPv4 Session Object Body with
MT-ID
Zhao, et al. Expires April 4, 2010 [Page 8]
Internet-Draft RSVP Muti Topology Extension Oct 2009
3.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 4: Format of P2MP LSP_TUNNEL_IPv6 Session Object Body with
MT-ID
4. Processing of Message with MT ID
Procedure changes for processing P2P and P2MP protocol messages with
MT ID: [TBD]
5. MPLS Forwarding in MT
In MT based MPLS network, forwarding will not only be based on label,
but also based on the MT-ID associsted with the label. There are
multiple options to do this. Below, we list three options.
5.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 exsiting 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 awared 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 April 4, 2010 [Page 9]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 coresspoding 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 5: FIB Entry Example for One Label Space
5.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 assocaited
with label. Each label forwarding entry will have an extra label
stacked with the orginal label. This extra label is used as the MT
identifer. For example, the forwarding entry in the LIB looks like
this:
Zhao, et al. Expires April 4, 2010 [Page 10]
Internet-Draft RSVP Muti Topology Extension Oct 2009
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 6: 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.
6. Reserved MT ID Values
Certain MT topologies are assigned to serve pre-determined purposes:
[TBD]
7. 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.
8. IANA Considerations
TBD
9. Acknowledgement
The authors would like to thank Dan Tappan and Nabil Bitar for their
valuable comments on this draft.
10. References
Zhao, et al. Expires April 4, 2010 [Page 11]
Internet-Draft RSVP Muti Topology Extension Oct 2009
10.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.
10.2. Informative References
Authors' Addresses
Quintin Zhao
Huawei Technology, Inc.
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
Zhao, et al. Expires April 4, 2010 [Page 12]
Internet-Draft RSVP Muti Topology Extension Oct 2009
Huaimo Chen
Huawei Technology, Inc.
125 Nagog Technology Park
Acton, MA 01719
US
Email: Huaimochen@huawei.com
Luyuang Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
US
Email: lufang@cisco.com
Chao Zhou
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
US
Email: czhou@cisco.com
Lianyuan Li
China Mobile, Inc.
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: lilianyuan@chinamobile.com
Xin Huang
China Mobile, Inc.
53A, Xibianmennei Ave.
Xunwu District, Beijing 01719
China
Email: huangxin@chinamobile.com
Zhao, et al. Expires April 4, 2010 [Page 13]