Internet DRAFT - draft-guo-rsvp-te-extensions
draft-guo-rsvp-te-extensions
Internet Engineering Task Force Dan Guo, Jibin Zhan,
Internet Draft Nanda Ravindran, Prakash Siva
draft-guo-rsvp-te-extensions-00.txt Wenjing Chu, Robert Cooper
July 2001 (Turin Networks)
Expiration Date Jan 2002 Raymond Cheung, James Fu
(Sorrento Networks)
Extensions to RSVP-TE for Supporting Diverse Path Protection
<draft-guo-rsvp-te-extensions.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
1. Abstract
This draft describes two specific extensions to RSVP-TE. The first
extension is concerned about the scalability of RSVP-TE. It proposes
expanding the length of tunnel ID in RSVP-TE session object, from 16
bits to 32 bits, in order to increase the upper limit of LSPs origin-
ated from one node. The second extension is to propose a new object
for representing a protection group. A protection group can tie two
or more diverse LSPs between a source-destination pair of nodes. This
extension is warranted due to the importance and wide-spread appli-
cations of LSP protection switching mechanisms. With this extension,
protection group information no longer is embedded into vendor-specific
opaque objects. These two extensions only require minor changes to RSVP-
TE protocol. When adopted into RSVP-TE, they will improve the scalability
of RSVP-TE and simplify the support of diverse LSP protection mechanisms.
2. 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.
3. Introduction
The Generalized MPLS (GMPLS) extends MPLS to encompass TDM (e.g., SONET
/SDH), Lambda Switch (LSC) and Fiber-Switching (FSC) [GMPLS-ARCH]. RSVP-
TE, a GMPLS-based signaling protocol, is required to handle the signaling
for provisioning of Label Switched Paths (LSPs) at a wide range of granu-
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 1]
larities [RSVP-TE][GMPLS-RSVP]. For example, SONET and SDH are two TDM
standards widely used by operators to transport signals multiplexed over
optical links. They possess a multiplexing hierarchy that includes a
coarse circuit such as STS-48 and a fine-granularity circuit such as VT
1.5 [SONET]. As a result, it is of importance for RSVP-TE to be scalable
in supporting a variety of switching technologies.
Additionally, there have been considerable efforts towards devising the
mechanism for supporting LSP protection and restoration. In the case of
optical transport networks (OTN), protection and restoration of transport
circuits is a capability universally required [BMS][RECOV]. With the
consideration of shared risk link group (SRLG) properties (see [SRLG]),
two or more diverse circuits can be provisioned between a pair of nodes,
to support various protection switching schemes (e.g., 1+1, 1:1, 1:n, m:n).
The goal of this draft is to describe two specific extensions to RSVP-
TE. The first extension is concerned about the scalability of RSVP-TE.
It proposes expanding the length of tunnel ID in RSVP-TE session object,
from 16 bits to 32 bits, in order to increase the upper limit of LSPs
originated from one node. In the latest RSVP-TE draft, tunnel ID occupies
32 bits but the higher 16 bits is mandated to be 0. This extension will
greatly extend the addressing space for tunnel ID.
The second extension is to propose a new object for representing a pro-
tection group. The protection group is a concept for tying two or more
diverse LSPs between a source-destination pair of nodes. This extension
is warranted due to the importance and wide-spread applications of the
LSP protection capability. For 1+1 or 1:1 protection switching schemes,
one LSP is a working LSP and the other LSP is the protection LSP. For
1:N (or M:N) protection switching scheme, one LSP (or M LPSs) is the
protection LSP shared by N working LSPs. Without this extension, the
current approach is to have each vendor create private (opaque) objects
for representing this information. This approach impairs the inter-
operability, since different nodes may be from different vendors using
different coding schemes.
These two extensions only require minor changes to RSVP-TE protocol. Their
implementation is straight-forward. When adopted into RSVP-TE, they will
improve the scalability of RSVP-TE and simplify the support of diverse LSP
protection mechanisms.
4. Extension 1: 32 Bits for Tunnel ID
An RSVP session is uniquely identified by a destination IP address, a
tunnel ID, an LSP ID, and an extended tunnel ID. An extended tunnel ID
is usually set to the source node IP address. An LSP ID is commonly
used for supporting the "make-before-break" feature.
Currently, RSVP-TE uses 16 bits to represent a tunnel ID while the 16
bits immediate to its left are mandated to be 0 [RSVP-TE].
LSP_TUNNEL_IPv4 Session Object
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 2]
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
IPv4 address of the egress node for the tunnel.
Tunnel ID
A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
For SONET/SDH, 16 bits are not enough. For example, at the VT 1.5 level,
under current specifications, a node can have at most 1.5Mps*2**16,
which is 96 Gbps. If a SONET node has more than 100 Gbps of combined
throughput, we may run out of the available tunnel IDs.
We propose a simple modification that allows tunnel ID to occupy 32 bits:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel ID
A 32-bit identifier used in the SESSION that remains constant
over the life of the tunnel.
5. Extension 2: Protection Group object
As discussed in section 3, two or more diverse paths are often provisioned
between a node-pair. Diverse paths are obtained by applying the SRLG
constraint criteria to the constraint-based path computation. They take
into account resource and logical structure disjointness that implies a
lower probability of simultaneous lightpath failure. Diverse paths can
form a protection group for providing various protection switching schemes
(including 1+1, 1:1, 1:N, M:N). A protection path in a protection group
can carry traffic identical to working traffic, or carry extra traffic, or
simply stand by.
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 3]
When a protection group is formed and provisioned, it is assigned an
identifier (ID) by the traffic engineering (TE) manager. A protection
group is uniquely defined by <source ID, destination ID, protection
group ID>.
A protection group contains a collection of LSPs. For example, one
primary LSP and one protection LSP for 1:1 or 1+1 protection schemes,
or N working LSPs and one protection LSP for 1:N protection.
We propose to add a new object for representing a protection group (PG).
The protection group provides a way to bond a number of LSPs together.
It is an optional object at the path level.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <TIME_VALUES> ]
[ <EXPLICIT_ROUTE> ]
[ PROTECTION_GROUP_OBJ ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
Class: TBD; C-type: TBD;
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Type| Index | reserved | M | N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION GROUP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1 bit Flag to indicate whether this path is protection or working;
F=0: working path;
F=1: protection path;
Type: 3-bit field, to indicate protection type;
0: 1+1;
1: 1:1;
2: 1:N;
3: M:N
Index: 4-bit field to indicate the rank of this path.
For example, when F=0 (i.e., working path), Type is 2 (i.e.,1:N) and
index =2, it means this path is the 2nd working.
Reserved: 8-bit field for future usage.
M: 8-bit field.
N: 8-bit field.
When type=0 (i.e., 1+1) or type=1 (i.e., 1:1), M and N must be 0;
When type=2 (i.e., 1:N), M must be 0 and N can be 0 to 255;
When type=3 (i.e., M:N), M and N can be 0 to 255.
Protection Group ID: 32-bit field to identify a protection group together
with source ID and destination ID.
Additional information regarding traffic types, such as extra traffic or Non-
preemptible Unprotected Traffic (NUT), can be added into this object. This is
left for future study.
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 4]
When a node receives a path message which contains the protection
group object, it can extract the protection information regarding
this path and pass it to the traffic engineering (TE) manager. It is
up to the TE manager to match all the diverse paths belonging to
the same protection group.
6. Security Considerations
The extensions specified here do not raise any security issues that
are not already present in the RSVP-TE architecture.
7. References
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description
Including Multiplex Structure, Rates, and Formats," ANSI
T1.105, 2000.
[RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp-lsp-
tunnel-08.txt, May 2001.
[GMPLS-ARCH] E. Mannie et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", Internet Draft, Work in progress,
draft-many-gmpls-architecture-00.txt, February 2001.
[GMPLS-SONET/SDH] E. Mannie Editor, "GMPLS Extensions for SONET and
SDH Control," Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt,
June 2001.
[GMPLS-RSVP] P. Ashwood-Smith et al., "Generalized MPLS Signaling
- RSVP-TE Extensions", Internet Draft, Work in progress, draft-ietf-
mpls-generalized-rsvp-te-03.txt, May 2001.
[BMS] G. Bernstein et al, "Framework for MPLS-based Control of Optical
SDH/SONET Networks", Internet Draft, draft-bms-optical-sdhsonet-mpls-
control-frmwrk-00.txt, November 2000
[RECOV] V. Sharma, et al, "Framework for MPLS-based Recovery," Internet
Draft, draft-ietf-mpls-recovery-frmwrk-02.txt, March 2001.
[SRLG] D. Papadimitriou, et al, "Inference of Shared Risk LInk Groups,"
Internet Draft, draft-many-inference-srlg-00.txt, Aug 2001.
8. Author's Addresses
Dan Guo, Jibin Zhan, N. Ravindran, P. Siva, Wenjing Chu, R. Cooper
Turin Networks, Inc.
1415 N. McDowell Blvd, Petaluma, CA 95454
Phone: +1 707-665-4357
Email: {dguo,jzhan,nravindran, psiva,wchu,rcooper}@turinnetworks.com
Raymond Cheung, James Fu
Sorrento Networks, Inc.
9990 Mesa Rim Road,
San Diego, CA 92121
Email: {rcheung,jfu}@sorrentonet.com
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 5]
9. Full Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in
its implementation may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as required
to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 6]
