Home A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) :: RFC3474

Network Working Group Z. Lin
Request for Comments: 3474 New York City Transit
Category: Informational D. Pendarakis
Tellium
March 2003

Documentation of IANA assignments for
Generalized MultiProtocol Label Switching (GMPLS)
Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
Usage and Extensions for
Automatically Switched Optical Network (ASON)

Status of this Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Abstract

The Generalized MultiProtocol Label Switching (GMPLS) suite of
protocol specifications has been defined to provide support for
different technologies as well as different applications. These
include support for requesting TDM connections based on Synchronous
Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as
Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS
suite of protocols, specifically GMPLS signaling using Resource
Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes
additional extensions to these signaling protocols to support the
capabilities of an ASON network.

This document proposes appropriate extensions towards the resolution
of additional requirements identified and communicated by the ITU-T
Study Group 15 in support of ITU's ASON standardization effort.

Lin & Pendarakis Informational [Page 1]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

Table of Contents

1. Conventions used in this document...............................3
2. Introduction....................................................3
3. Support for Soft Permanent Connection...........................3
4. Support for Call................................................4
4.1 Call Identifier and Call Capability........................4
4.1.1 Call Identifier.....................................4
4.1.2 Call Capability.....................................7
4.2 What Does Current GMPLS Provide............................7
4.3 Support for Call and Connection............................7
4.3.1 Processing Rules....................................8
4.3.2 Modification to Path Message........................8
4.3.3 Modification to Resv Message........................9
4.3.4 Modification to PathTear Message....................9
4.3.5 Modification to PathErr Message....................10
4.3.6 Modification to Notify Message.....................10
5. Support For Behaviors during Control Plane Failures...........11
6. Support For Label Usage.......................................12
7. Support for UNI and E-NNI Signaling Session...................13
8. Additional Error Cases........................................14
9. Optional Extensions for Supporting
Complete Separation of Call and Connection....................15
9.1 Call Capability.........;.................................15
9.2 Complete Separation of Call and
Connection (RSVP-TE Extensions)...........................16
9.2.1 Modification to Path...............................16
9.2.2 Modification to Resv...............................17
9.2.3 Modification to PathTear...........................18
9.2.4 Modification to PathErr............................18
9.2.5 Modification to Notify.............................18
10. Security Considerations.......................................19
11. IANA Considerations...........................................19
11.1 Assignment of New Messages...............................19
11.2 Assignment of New Objects and Sub-Objects................19
11.3 Assignment of New C-Types................................20
11.4 Assignment of New Error Code/Values......................20
12. Acknowledgements..............................................20
13. References....................................................21
13.1 Normative References.....................................21
13.2 Informative References...................................22
14. Intellectual Property.........................................23
15. Contributors Contact Information..............................24
16. Authors' Addresses............................................24
17. Full Copyright Statement......................................25

Lin & Pendarakis Informational [Page 2]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

1. 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 BCP 14, RFC 2119
[RFC2119].

2. Introduction

This document contains the extensions to GMPLS for ASON-compliant
networks [G7713.2]. The requirements describing the need for these
extensions are provided in [GMPLS-ASON] as well as [ASON-RQTS].
These include:

- Support for call and connection separation
- Support for soft permanent connection
- Support for extended restart capabilities
- Additional error codes/values to support these extensions

This document concentrates on the signaling aspects of the GMPLS
suite of protocols, specifically GMPLS signaling using RSVP-TE. It
introduces extensions to GMPLS RSVP-TE to support the capabilities as
specified in the above referenced documents. Specifically, this
document uses the messages and objects defined by [RFC2205],
[RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476]
as the basis for the GMPLS RSVP-TE protocol, with additional
extensions defined in this document.

3. Support for Soft Permanent Connection

In the scope of ASON, to support soft permanent connection (SPC) for
RSVP-TE, one new sub-type for the GENERALIZED_UNI object is defined.
The GENERALIZED_UNI object is defined in [RFC3476] and [OIF-UNI1].
This new sub-type has the same format and structure as the
EGRESS_LABEL (the sub-type is the suggested value for the new sub-
object):

- SPC_LABEL (Type=4, Sub-type=2)

The label association of the permanent ingress segment with the
switched segment at the switched connection ingress node is a local
policy matter (i.e., between the management system and the switched
connection ingress node) and is thus beyond the scope of this
document.

Lin & Pendarakis Informational [Page 3]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

The processing of the SPC_LABEL sub-object follows that of the
EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit
label control described in [RFC3471] and [RFC3473] may provide a
mechanism to support specifying the egress label in the context of
supporting the GMPLS application, the SPC services support for the
ASON model uses the GENERALIZED_UNI object for this extension to help
align the model for both switched connection and soft permanent
connection, as well as to use the service level and diversity
attributes of the GENERALIZED_UNI object.

4. Support for Call

To support basic call capability (logical call/connection
separation), a call identifier is introduced to the RSVP-TE message
sets. This basic call capability helps introduce the call model;
however, additional extensions may be needed to fully support the
canonical call model (complete call/connection separation).

4.1 Call Identifier and Call Capability

A Call identifier object is used in logical call/connection
separation while both the Call identifier object and a Call
capability object are used in complete call/connection separation.

4.1.1 Call Identifier

To identify a call, a new object is defined for RSVP-TE. The CALL_ID
object carries the call identifier. The value is globally unique
(the Class-num is the suggested value for the new object):

CALL_ID (Class-num = 230)

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call identifier |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the following C-types are defined:

- C-Type = 1 (operator specific): The call identifier contains an
operator specific identifier.

- C-Type = 2 (globally unique): The call identifier contains a
globally unique part plus an operator specific identifier.

Lin & Pendarakis Informational [Page 4]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

The following structures are defined for the call identifier:

- Call identifier: generic [Length*8-32]-bit identifier. The number
of bits for a call identifier must be multiples of 32 bits, with a
minimum size of 32 bits.

The structure for the globally unique call identifier (to guarantee
global uniqueness) is to concatenate a globally unique fixed ID
(composed of country code, carrier code, unique access point code)
with an operator specific ID (where the operator specific ID is
composed of a source LSR address and a local identifier).

Therefore, a generic CALL_ID with global uniqueness includes (composed of plus plus ) and (composed of plus ). For a CALL_ID that only
requires operator specific uniqueness, only the is needed, while for a CALL_ID that is required to be globally
unique, both and are needed.

The shall consist of a three-character International
Segment (the ) and a twelve-character National Segment
(the plus ). These
characters shall be coded according to ITU-T Recommendation T.50. The
International Segment (IS) field provides a 3 character ISO 3166
Geographic/Political Country Code. The country code shall be based
on the three-character uppercase alphabetic ISO 3166 Country Code
(e.g., USA, FRA).

National Segment (NS):
The National Segment (NS) field consists of two sub-fields:

- the first subfield contains the ITU Carrier Code
- the second subfield contains a Unique Access Point Code.

The ITU Carrier Code is a code assigned to a network operator/service
provider, maintained by the ITU-T Telecommunication Service Bureauin
association with Recommendation M.1400. This code consists of 1-6
left-justified alphabetic, or leading alphabetic followed by numeric,
characters (bytes). If the code is less than 6 characters (bytes),
it is padded with a trailing NULL to fill the subfield.

The Unique Access Point Code is a matter for the organization to
which the country code and ITU carrier code have been assigned,
provided that uniqueness is guaranteed. This code consists of 1-6
characters (bytes), trailing NULL, completing the 12-character
National Segment. If the code is less than 6 characters, it is
padded by a trailing NULL to fill the subfield.

Lin & Pendarakis Informational [Page 5]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

Format of the National Segment

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrier code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrie dode (cont) | Unique access point code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique access point code (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the Call identifier field for C-Type = 1:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lin & Pendarakis Informational [Page 6]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

The format of the Call identifier field for C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | IS (3 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NS (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In both cases, a "Type" field is defined to indicate the type of
format used for the source LSR address. The Type field has the
following meaning:
For Type=0x01, the source LSR address is 4 bytes
For Type=0x02, the source LSR address is 16 bytes
For Type=0x03, the source LSR address is 20 bytes
For type=0x04, the source LSR address is 6 bytes
For type=0x7f, the source LSR address has the length defined by
the vendor

Source LSR address:
An address of the LSR controlled by the source network.

Local identifier:
A 64-bit identifier that remains constant over the life of
the call.

Note that if the source LSR address is assigned from an address space
that is globally unique, then the operator-specific CALL_ID may also
be used to represent a globally unique CALL_ID. However, this is not
guaranteed since the source LSR address may be assigned from an
operator-specific address space.

Lin & Pendarakis Informational [Page 7]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

4.1.2 Call Capability

The call capability feature is provided in Section 10. This is an
optional capability. If supported, section 10 extensions must be
followed.

4.2 What Does Current GMPLS Provide

The signaling mechanism defined in [RFC2961], [RFC3209] and [RFC3471]
supports automatic connection management; however it does not provide
capability to support the call model. A call may be viewed as a
special purpose connection that requires a different subset of
information to be carried by the messages. This information is
targeted to the call controller for the purpose of setting up a
call/connection association.

4.3 Support for Call and Connection

Within the context of this document, every call (during steady state)
may have one (or more) associated connections. A zero connection
call is defined as a transient state, e.g., during a break-before-
make restoration event.

In the scope of ASON, to support a logical call/connection
separation, a new call identifier is needed as described above. The
new GENERALIZED_UNI object is carried by the Path message. The new
CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and
Notify messages. The ResvConf message is left unmodified. The
CALL_ID object (along with other objects associated with a call,
e.g., GENERALIZED_UNI) is processed by the call controller, while
other objects included in these messages are processed by the
connection controller as described in [RFC3473]. Processing of the
CALL_ID (and related) object is described in this document.

Note: unmodified RSVP message formats are not listed below.

4.3.1 Processing Rules

The following processing rules are applicable for call capability:

- For initial calls, the source user MUST set the CALL_ID's C-Type
and call identifier value to all-zeros.
- For a new call request, the first network node sets the
appropriate C-type and value for the CALL_ID.
- For an existing call (in case CALL_ID is non-zero) the first
network node verifies existence of the call.

Lin & Pendarakis Informational [Page 8]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

- The CALL_ID object on all messages MUST be sent from the ingress
call controller to egress call controller by all other
(intermediate) controllers without alteration. Indeed, the
Class-Num is chosen such that a node which does not support ASON
extensions to GMPLS forwards the object unmodified (value in the
range 11bbbbbb).
- The destination user/client receiving the request uses the CALL_ID
value as a reference to the requested call between the source user
and itself. Subsequent actions related to the call uses the
CALL_ID as the reference identifier.

4.3.2 Modification to Path Message

::=
[ ]
[ [ |
] ... ]
[ ]

[ ]

[ ]
[ ]
[ ... ]
[ ]
[ ]
[ ]
[ ]
[ ... ]

The format of the sender descriptor for unidirectional LSPs is not
modified by this document.

The format of the sender descriptor for bidirectional LSPs is not
modified by this document.

Note that although the GENERALIZED_UNI and CALL_ID objects are
optional for GMPLS signaling, these objects are mandatory for ASON-
compliant networks, i.e., the Path message MUST include both
GENERALIZED_UNI and CALL_ID objects.

Lin & Pendarakis Informational [Page 9]

RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003

4.3.3 Modification to Resv Message

::=
[ ]
[ [ |
] ... ]
[ ]

[ ]
[ ]

[ ]
[ ]
[ ... ]