GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup
draft-martinelli-ccamp-optical-imp-signaling-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 11, 2008.

Abstract

The problem of provisioning a light-path in a transparent dense wavelength division multiplexing (DWDM) optical island requires the transmission of optical impairment related parameters along the selected route. In this draft we propose the GMPLS signaling protocol (RSVP/RSVP-TE) extensions to transmit optical impairments to setup an optically feasible light-path.

Table of Contents

1.  Introduction
2.  Conventions Used in This Document
3.  Optical Path Validation Procedure
4.  Physical Parameter Classification and top level TLV
5.  Optical Service Parameters sub-TLV
    5.1.  Forward Error Correction (FEC)
    5.2.  Modulation Format
6.  Optical Path Parameters sub-TLV(s)
    6.1.  Mandatory Linear Optical Parameters
    6.2.  Optional Linear Optical Parameters
7.  Message Fragmentation
8.  Backward Compatibility
9.  Error management
10.  Acknowledgements
11.  Contributing Authors
12.  IANA Considerations
13.  Security Considerations
14.  References
    14.1.  Normative References
    14.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The current Generalized Multi-Protocol Label Switching (GMPLS) specification [RFC3945] (Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” October 2004.) and the signalling related documents ([RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.), [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.), [RFC4328] (Papadimitriou, D., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control,” January 2006.)) support optical interfaces with different switching capability to setup a light-path while [RFC4054] (Strand, J. and A. Chiu, “Impairments and Other Constraints on Optical Layer Routing,” May 2005.) defines routing optical constrains on routing. [I‑D.bernstein‑ccamp‑wavelength‑switched] (Bernstein, G., “Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks,” February 2008.), defines a framework for identifying key components and issues pertaining to wavelength switched optical networks (WSON). [I‑D.otani‑ccamp‑gmpls‑lambda‑labels] (Otani, T., Guo, H., Miyazaki, K., Caviglia, D., and Z. Ali, “Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR),” February 2008.) propose a global semantic for wavelength generalized labels taking into account light-path specific needs.

In transparent optical networks, physical impairments incurred by non-ideal optical transmission medium accumulate along an optical path. Because of these impairments even if two nodes are connected through an optical path, there is no guarantee that the optical signal (light) reaches the end node with acceptable signal quality, for example in terms of BER/OSNR/Q-factor limit. For a successful light-path provisioning in a WSON, the set up process must be aware of a set of physical impairments that has effect on the light-path. A complete set of physical impairments will include linear and non-linear impairments. This preliminary draft proposes a way to collect the optical path linear impairments in the signaling phase by providing suitable extensions to signaling protocol (RSVP/RSVP-TE) assuming that non-linear impairments effects are handled in the network design phase considering a bounded OSNR margin [RFC4054] (Strand, J. and A. Chiu, “Impairments and Other Constraints on Optical Layer Routing,” May 2005.).

The management of physical impairments is done only in the signalling process and it does not require any extension to the traffic engineering database.

The set of parameters carried by the signaling protocol is divided into optical service parameters and optical path parameters:

• The optical service parameters describe the requested signal type, are related to the characteristics of the transponder at source node and hence are not changed at transit nodes.
• The optical path parameters describe the signal characteristics evolution along the path from source node to destination node, are related to the characteristics of the various links/subsystems and are updated at each transit node. They are divided into mandatory and optional parameters. The mandatory parameters are related to feasibility constraints such as power and OSNR, whereas the optional parameters are extendable linear impairments such as chromatic dispersion (CD), polarization mode dispersion (PMD), crosstalk, etc. The optional parameters can be used to evaluate the feasibility of a light-path more accurately as an alternate solution to the bounded OSNR margin evaluation. Parameter update methods might use appropriate physical models and are out of scope of this document.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

In additions this document will use terminology from [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.), [RFC3209] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.), [RFC4054] (Strand, J. and A. Chiu, “Impairments and Other Constraints on Optical Layer Routing,” May 2005.), and [I‑D.bernstein‑ccamp‑wavelength‑switched] (Bernstein, G., “Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks,” February 2008.).

3.  Optical Path Validation Procedure

The signaling based validation of an optical path in downstream direction in a transparent network (lambda switched LSP) is implemented by the following procedure:

• The source node signals in the Path message the supported signal types (FEC and modulation format) and wavelength set (encoded in the LABEL_SET Object) depending on available local transponders.
• Transit nodes update the Path message pruning non cross-connectable wavelengths (LABEL_SET Object) and computing or measuring the path optical characteristics up to the outgoing interface (optical impairments).
• Destination node selects the wavelength and the signal type based on the signaled optical impairments and the available local transponders (supported wavelengths, sensitivity to optical impairments) and signals the selection in the Resv message.
• Intermediate nodes process the Resv message cross-connecting the selected wavelength in incoming and outgoing ports (wavelength continuity constraint).
• The source node cross-connects the selected wavelength to a local transponder supporting the selected signal type (FEC and modulation format).

The unavailability of cross-connectable wavelength in intermediate nodes or of transponders supporting the signal in the destination node causes the request failure (PathErr message).

The unavailability of the selected wavelength in intermediate nodes or of transponders supporting the signal in the source node (race condition in allocating resources) causes the request failure (ResvErr message).

In this document, only the encoding in the RSVP messages of the optical information needed to support the described procedure is defined. The specific policies used to select the resources (wavelength and transponders), the models to compute the optical impairments and the procedure to validate the signal with respect to the transponder sensitivity are not in the scope of this document.

4.  Physical Parameter Classification and top level TLV

The extensions required to RSVP/RSVP-TE to make them aware of optical impairments and to setup optically feasible light-paths requires the following information:

• Optical Service Parameters.
  The standard GENERALIZED_LABEL_REQUEST and TSPEC/FLOW_SPEC objects support the encoding of the information related to service type and service QoS. However for DWDM networks the end node of an LSP has to know a certain set of specific optical parameters related to transmitting interface. Section 5 (Optical Service Parameters sub-TLV) reports details of these parameters and their encoding.
• Optical Path Parameters.
  These attributes are required to support transmission of physical impairment parameters required for the optical path feasibility evaluation. Details are presented in Section 6 (Optical Path Parameters sub-TLV(s)).

This document defines how to encode the above information through new TLVs according to [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),” February 2006.).

The proposed encoding scheme for the optical parameters defines a TLV (channel optical physical information) associated to a wavelength and a set of sub-TLV for each set of service and path parameters.

Additional set of parameters can be added without affecting the already defined encoding.

A TLV sub-object for each available wavelength (PATH message) or selected wavelength (RESV message) is encoded in an LSP_REQUIRED_ATTRIBUTES Object.

The TLV sub-object encoding is defined in the next picture.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Wavelength ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//               Parameters Sub-TLV Sequence                   //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: optical channel physical parameters info TLV type (TBA).

Length: length of the TLV object in bytes without the 4 byte header.

Wavelength ID: wavelength label identifier according to [I‑D.otani‑ccamp‑gmpls‑lambda‑labels] (Otani, T., Guo, H., Miyazaki, K., Caviglia, D., and Z. Ali, “Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR),” February 2008.).

Parameters Sub-TLV Sequence: service and path parameters values.

The Sub-TLV format is defined in the next picture

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |    Flags      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//               Value                                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: Sub-TLV type

Flags: bit-mask defining the management of the Sub-TLV

bit 0: Mandatory if set, Optional if unset

bit 1: ToUpdate if set, Constant if unset

bit 2-7: to be assigned

Length: Value field length in bytes

Value: variable length Sub-TLV content

The Flags field defines how intermediate nodes manage unrecognized Sub-TLV:

Unrecognized Constant sub-TLVs are forwarded as-is

Unrecognized Mandatory and ToUpdate sub-TLVs cause the reject with a failure of the request

Unrecognized Optional and ToUpdate sub-TLVs are silently dropped from the TLV (the value would be inaccurate)

5.  Optical Service Parameters sub-TLV

The Optical Service Parameters defines the signal transmissions characteristics at the source node. This type of information is required at the destination node to verify the optical signal compatibility.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Flags      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             FEC 1             |           Mod Format 1        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                                                             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             FEC n             |           Mod Format n        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: sub-TLV type (=1)

Flags: Mandatory, Constant

Length: length of the sub-TLV value in bytes

FEC: supported Forward Error Correction Modes (see Section 5.1 (Forward Error Correction (FEC))

Mod Format: supported modulation formats (see Section 5.2 (Modulation Format)) associated with the FEC.

This sub-TLV is used in the PATH message to signal the full list of optical parameters associated with physical interfaces (signal types and wavelengths) available at the source node. In the RESV message this information is associated to the selected receiving interface at the destination node. In the RESV message only one tuple (FEC, Mod Format) will be specified.

5.1.  Forward Error Correction (FEC)

FEC (16 bits) field is the Forward Error Correction and has the following values:

0: no FEC

1: standard FEC (according to [ITU.G709] (International Telecommunications Union, “Interface for the Optical Transport Network (OTN),” March 2003.))

2-9: super-FEC according to sub clauses from I.2 to I.9 of [ITU.G975.1] (International Telecommunications Union, “Forward Error Correction for high bit rate DWDM Submarine Systems,” February 2004.)

Values of the format 1bbb.bbbb.bbbb.bbbb are left to represent vendor specific or proprietary FEC encoding.

5.2.  Modulation Format

Mod Format (16 bits) is the available modulation format at the source node. Currently the field takes the following values:

0: NRZ

1: Duo Binary

2: DPSK

Other values might be defined in the future as technology advance. Also here values with the format 1bbb.bbbb.bbbb.bbbb are left to represent vendor specific or proprietary modulation formats.

6.  Optical Path Parameters sub-TLV(s)

For each available channel, this set of parameters has to be carried through the PATH message to allow the optical feasibility evaluation. At each hop, the optical node will update these values according to information locally available at the node (say internal amplifiers, wavelength cross connect, etc.). The way an optical node gets knowledge of this required information (e.g. through NMS, auto-discovery etc.) is out of the scope of this document.

This document defines two groups of linear optical parameters. Each group will have its own sub-TLV.

Mandatory Linear Optical Parameters

This set includes Optical Signal Power and the OSNR with associated variances. It represents a minimum set to asses the feasibility of an optical path. This set will be encoded using a mandatory sub-TLV.

Optional Linear Optical Parameters

This set includes CD, PMD, XT with associated variances. These parameters represent an additional set to allow a more accurate optical feasibility evaluation. This set will be encoded using an optional sub-TLV.

Separation between Mandatory and Optional allows a rough optical feasibility evaluation where network elements support at least the Mandatory set. Depending on how a WSON is designed, the usage of the mandatory set could be an operational choice not to overwhelm the control plane while maintaining reliable feasibility estimation. Moreover it might happens that not all nodes in a networks support both sets of optical path parameters. With this separation, the light-path signalling still continues to work with a less accurate evaluation.

The choice of optional set of parameters depends on several considerations. They are among those reported by the [RFC4054] (Strand, J. and A. Chiu, “Impairments and Other Constraints on Optical Layer Routing,” May 2005.) and provide sufficient accuracy for the linear impairments evaluation.

For each parameter an error estimation is associated (variance); if no error estimation is provided the value MUST be zero.

6.1.  Mandatory Linear Optical Parameters

The Sub-TLV encode the values of the optical parameters of the channel (wavelength) associated to the TLV, measured at the node egress interface.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Flags      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Signal Optical Power                                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Signal Optical Power Variance                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  OSRN                                                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  OSNR Variance                                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: sub-TLV type (TBA).

Flags: Mandatory, ToUpdate.

Length: length of the sub-TLV value in bytes.

Signal Optical Power. 32-bit IEEE floating point number. Measurement Unit: dBm.

Signal Optical Power Variance. 32-bit IEEE floating point number.

OSNR. 32-bit IEEE floating point number. Measurement Unit: dB.

OSNR Variance. 32-bit IEEE floating point number.

6.2.  Optional Linear Optical Parameters

The Sub-TLV encode the values of the optional optical parameters of the channel (wavelength) associated to the TLV, measured at the node egress interface. This Sub_TLV is defined as LSP_ATTRIBUTES.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |    Flags      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  CD                                                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  CD Variance                                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  PMD                                                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  PMD Variance                                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  CrossTalk                                                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  CrossTalk Variance                                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: sub-TLV type (TBA).

Flags: Optional, ToUpdate.

Length: length of the sub-TLV value in bytes.

CD, Chromatic Dispersion. 32-bit IEEE floating point number. Measurement Unit: ps/nm.

CD Variance. 32-bit IEEE floating point number.

PMD, Polarization Mode Dispersion. 32-bit IEEE floating point number. Measurement Unit: ps.

PMD Variance. 32-bit IEEE floating point number.

CrossTalk. 32-bit IEEE floating point number. Measurement Unit: dB.

CrossTalk Variance. 32-bit IEEE floating point number.

7.  Message Fragmentation

In certain cases, the state information carried by the Path message can be quite large. Size estimation for a physical Optical Channel TLV (see Figure 1) can be the following: 8 bytes for type, length and wavelength ID plus, 16 bytes for the Optical Service Parameters sub-TLV considering 3 FEC/modulation format combinations plus, 20 bytes for the Mandatory Linear Optical Path parameters plus 28 bytes for the Optional Linear Optical Parameter sub-TLV. Total is 44 bytes for each wavelength by just considering mandatory sub-TLVs and 72 bytes by considering also the optional part. Given the number of wavelengths today available in DWDM networks, the size of the path message end up in large values. For example to signal just 32 wavelengths the size required for the physical optical parameters ranges at least from 1408 to 2304 bytes.

One possible option is to let the application layer requesting the light-path setup to decide how many wavelengths to signal. So, for example, the application layer might ask to signal at most 10 wavelengths at a time to make sure the path message will stay within the MTU limit for its network.

A second solution proposed here allows the semantic fragmentation as suggested by RSVP (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) [RFC2205]. The proposed encoding extends the SENDER_TEMPLATE with new ClassType (derived from the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 RSVP-TE (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.) [RFC3209]). The Object includes the information on the "fragment id" and the requested policy at the destination node

Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv4 C-Type = TBA

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 sender address                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Reserved                |            LSP ID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo       |  MsgId        |  P    |  Timeout              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv6 C-Type = TBA

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 sender address                  |
+                                                               +
|                            (16 bytes)                         |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Reserved                |            LSP ID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo       |  MsgId        |  P    |  Timeout              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Besides fields already defined in the SENDER_TEMPLATE, the following fields are defined here:

• TotalNo: 8 bit integer representing the total number of Path messages issued by the source node to setup a single light-path. When this values is equals to 1 all the other fields MUST be ignored.
• MsgId: 8 bit integer representing a sequential number of a single Path request. Its value must be between 1 and TotalNo, both inclusive.
• P: Policy the destination node must apply upon receiving a fragmented path request:

  1: Take the first message arrived and ignore the following ones.

  2: After the first message arrived, wait for any messages within the specified Timeout.

  3: After the first message arrived, waits for all messages. Fail, if the timeout expires, and there's at least one message missing

  The Destination node should "reject" (PathERR) all the requests except for the selected one, even if it could rely on the RSVP timeout to clear the unselected requests status in intermediate nodes.
• Timeout: 12 bits integer number representing the timeout value used by the policy. The value is in s/100 (hundreds of seconds) All messages MUST have the same value.

This type of encoding is a generic solution to manage the semantic fragmentation and its not strictly related to optical parameters encoding.

8.  Backward Compatibility

The TLV usage as defined by [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),” February 2006.) will guarantee the co-existence of nodes supporting normal RSVP-TE operations and node with optical impairment signaling capability.

A service with the new feature (optical feasibility evaluation) can be setup only if all the nodes in the path support the extensions. Optical Path Parameters are updated hop-by-hop and evaluated at destination node. If an intermediate node does not support the extensions the collected information is unreliable and the Path request MUST be rejected.

9.  Error management

No additional error code is introduced to manage requests failures; the behavior defined in [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),” February 2006.) applies to the management of the LSP_REQUIRED_ATTRIBUTES Object.

10.  Acknowledgements

11.  Contributing Authors

This document was the collective work of several authors. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in appropriate section and is not repeated below):

   Gabriele Maria Galimberti              Alberto Tanzi
   Cisco Systems                          Cisco Systems
   via Philips 12                         via Philips 12
   Monza  20052                           Monza  20052
   Italy                                  Italy

   Email: ggalimbe@cisco.com              Email: atanzi@cisco.com

   Domenico La Fauci                      Stefano Piciaccia
   Cisco Systems                          Cisco Systems
   via Philips 12                         via Philips 12
   Monza  20052                           Monza  20052
   Italy                                  Italy

   Email: dlafauci@cisco.com              Email: spiciacc@cisco.com


   Elio Salvadori                         Yabin  Ye
   CREATE-NET                             CREATE-NET
   via della Cascata 56c, Povo            via della Cascata 56c, Povo
   Trento  38100                          Trento  38100
   Italy                                  Italy

   Email: elio.salvadori@create-net.org   Email: yabin.ye@create-net.org


   Chava Vijaya Saradhi
   CREATE-NET
   via della Cascata 56c, Povo
   Trento  38100
   Italy

   Email: saradhi.chava@create-net.org

12.  IANA Considerations

This memo needs the follwing request to IANA

TLV (see Figure 1 in Section 4 (Physical Parameter Classification and top level TLV))

New class type for sender template (see Section 7 (Message Fragmentation))

All drafts are required to have an IANA considerations section (see the update of RFC 2434 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” March 2008.) [I‑D.narten‑iana‑considerations‑rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

13.  Security Considerations

This document introduces no new security considerations to [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.). GMPLS security is described in section 11 of [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.) and refers to [RFC3209] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.) for RSVP-TE.

14.  References

14.1. Normative References

14.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.