TOC 
Internet Engineering Task ForceG. Martinelli, Ed.
Internet-DraftCisco Systems
Intended status: Standards TrackA. Zanardi, Ed.
Expires: April 28, 2011CREATE-NET
 October 25, 2010


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

Abstract

The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility.

Status of this Memo

This Internet-Draft is submitted 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 April 28, 2011.

Copyright Notice

Copyright (c) 2010 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 (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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.



Table of Contents

1.  Introduction
2.  Conventions Used in This Document
3.  Optical Path Impairment Validation
    3.1.  Procedure for Distributed Validation
    3.2.  The Wavelenght Assignment Problem
4.  Optical Parameters Classification
5.  Information Encoding
6.  Optical Service Parameters sub-TLV
    6.1.  Forward Error Correction (FEC)
    6.2.  Modulation Format
7.  Optical Path Parameters sub-TLV(s)
    7.1.  Optical Parameter sub-TLV overview
    7.2.  Mandatory Linear Optical Parameters sub-TLVs
        7.2.1.  Optical Power
        7.2.2.  Optical Signal to Noise Ratio
    7.3.  Optional Linear Optical Parameters sub-TLVs
        7.3.1.  Chromatic Dispersion (CD)
        7.3.2.  Polarization Mode Dispersion (PMD)
        7.3.3.  Cross-Talk (XT)
8.  Message Fragmentation
9.  Backward Compatibility
10.  Error management
11.  Acknowledgments
12.  Contributing Authors
13.  IANA Considerations
14.  Security Considerations
15.  References
    15.1.  Normative References
    15.2.  Informative References
§  Authors' Addresses




 TOC 

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 signaling 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. Current optical switching technologies allow implementation of Wavelength Switched Optical Networks (WSON) and their relationship with control plane are defined within framework [I‑D.ietf‑ccamp‑rwa‑wson‑framework] (Bernstein, G., Lee, Y., and W. Imajuku, “Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON),” October 2010.) and related documents.

The implementation technology for the WSON is the Dense Wavelength Division Multiplexing (DWDM) and, one of the key issue is the physical impairments incurred by non-ideal optical transmission medium that accumulate along an optical path. For a successful lightpath provisioning in a WSON, the set up process must be aware of a set of physical impairments that has effect on the lightpath. From control plane perspetive the WSON probelm is divied within two main categories: the routing and waveleght assigment problem (as the framework above), and the impairment awareness. For this case the framework [I‑D.ietf‑ccamp‑wson‑impairments] (Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M., Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan, M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D. Caviglia, “A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments,” October 2010.). provides the motivation why optical impairments are important and details all possible. control plane architectural options.

This memo apply to an Impairment Validation process (IV) defined within the framework as Distributed process and it is related to the approximated scenario ([I‑D.ietf‑ccamp‑wson‑impairments] (Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M., Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan, M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D. Caviglia, “A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments,” October 2010.) Scenario C, section 3.1). Proposes extensions relates to signaling protocol (RSVP/RSVP-TE) as a way to collect and verify optical impairments for a lightpath setup. The management of optical impairments is done only in the signaling process and it does not require any extension to the traffic engineering database and routing protocols or Path Computational Element (PCE).

For what regarding signaling, WSON network require already some specific extentions as defined within [I‑D.ietf‑ccamp‑wson‑signaling] (Bernstein, G., Andriolli, N., Giorgetti, A., Guo, L., Harai, H., Ji, Y., King, D., Lee, Y., and S. Xu, “Signaling Extensions for Wavelength Switched Optical Networks,” October 2010.). This document will add some specific information referring to the IV process.



 TOC 

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.ietf‑ccamp‑rwa‑wson‑framework] (Bernstein, G., Lee, Y., and W. Imajuku, “Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON),” October 2010.).



 TOC 

3.  Optical Path Impairment Validation

This section report an high level description on how the the distributed IV process will work. From a procedural aspect it will be compatible with both RWA and distributed wavelenght assignment process.



 TOC 

3.1.  Procedure for Distributed Validation

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

In the Path message processing, the unavailability of cross-connectable wavelength in transit nodes or of transponders supporting the signal in the egress node causes the request failure (PathErr message).

In the Resv message processing, the unavailability of the selected wavelength in transit nodes or of transponders supporting the signal in the ingress node (race condition in allocating resources) causes the request failure (ResvErr message).

This procedure forces the meeting of the wavelength continuity constraint: the final effect of pruning wavelengths (e.g. removing labels from the LABEL_SET object) in transit nodes is the implementation of a wavelength selection process in the signaling phase. The wavelength assignment will be done at the egress node among all available wavelength for the LSP. The criteria used by the egress node to assign the wavelength is out of the scope of this document and is reported in [I‑D.ietf‑ccamp‑wson‑signaling] (Bernstein, G., Andriolli, N., Giorgetti, A., Guo, L., Harai, H., Ji, Y., King, D., Lee, Y., and S. Xu, “Signaling Extensions for Wavelength Switched Optical Networks,” October 2010.)



 TOC 

3.2.  The Wavelenght Assignment Problem

The impairment framework document [I‑D.ietf‑ccamp‑wson‑impairments] (Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M., Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan, M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D. Caviglia, “A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments,” October 2010.) details how the Routing and Wavelength Assignment (RWA) function and the Impairment Validation (IV) function can be combined withing different architectural options.

The distributed IV as detailed in this memo is compatible with different options for implementing the WA function. In case the WA function is implemented elsewhere the procedure above still apply apart from considering a single wavelength instead of a wavelength set. If optical validation fail along the path, instead of pruning a wavelet, the node will reply directly with a PathErr and the Lightpath setup will fail.



 TOC 

4.  Optical Parameters Classification

The set of optical parameters carried by the signaling protocol is divided into optical service parameters and optical path parameters. The actual list is defined elsewhere like [ITU.G680] (International Telecommunications Union, “Physical transfer functions of optical network elements,” July 2007.) and [I‑D.bernstein‑wson‑impairment‑info] (Lee, Y., Bernstein, G., Systems, C., Martinelli, G., and A. Zanardi, “Information Model for Impaired Optical Path Validation,” October 2010.). Scope of this section is just to propose a classification appropriate for RSVP-TE encoding.



 TOC 

5.  Information Encoding

This document defines how to encode the above information through new TLVs according to [RFC5420] (Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, “Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE),” February 2009.).

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

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                   //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 1 

The TLVs wavelength ID value must be consistent with the presence of LABEL_SET objects and its actions as defined within [RFC3471] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” January 2003.) and [RFC3473] (Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” January 2003.).

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                                         //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 2 

Type: Sub-TLV type

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

bit 0: if set the parameter is mandatory, otherwise it is optional.

bit 1: if set the parameter is variable and MUST be updated with the local value, otherwise it is a constant value set by the ingress node.

bit 2-7: not used.

Length: total length of the sub-TLV including header in octects.

Value: variable length Sub-TLV content

The Flags field defines how transit nodes manage the Sub-TLV:



 TOC 

6.  Optical Service Parameters sub-TLV

The Optical Service Parameters define the signal transmissions characteristics at the ingress node. This type of information is required at the egress 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        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 3 

Type: sub-TLV type (=1)

Flags: Mandatory, Constant

Length: total length of the sub-TLV including header in octets

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

Mod Format: supported modulation formats (see Section 6.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 the interface (signal types and wavelengths) available at the ingress node. A DWDM interface might have several sets of optical parameters available, for example a tunable interface has a set of possible wavelengths, together with a set of possible FEC encoding or modulation formats. In the RESV message this information is associated to the selected receiving interface at the egress node. In the RESV message only one tuple (FEC, Mod Format) will be specified.



 TOC 

6.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 with the format 1bbbbbbbbbbbbbbb are left to represent vendor specific or proprietary FEC encoding.



 TOC 

6.2.  Modulation Format

Editorial Node: this encoding section need to be reviewed with [I‑D.ietf‑ccamp‑wson‑signaling] (Bernstein, G., Andriolli, N., Giorgetti, A., Guo, L., Harai, H., Ji, Y., King, D., Lee, Y., and S. Xu, “Signaling Extensions for Wavelength Switched Optical Networks,” October 2010.).

Mod Format (16 bits) is the modulation and has the following values:

0: NRZ

1: Duo Binary

2: DPSK

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



 TOC 

7.  Optical Path Parameters sub-TLV(s)

This set of parameters is carried in the PATH message for each available wavelength to allow the optical feasibility evaluation. At each hop, the optical node MUST update these values according to information locally available at the node (say internal amplifiers, wavelength cross connect, etc.). This sub-TLV implements the Distributed Impairment evaluation as per [I‑D.bernstein‑wson‑impairment‑info] (Lee, Y., Bernstein, G., Systems, C., Martinelli, G., and A. Zanardi, “Information Model for Impaired Optical Path Validation,” October 2010.)

The way an optical node gets knowledge of this required information (e.g. through network management system, auto-discovery etc.) is out of the scope of this document and highly depends on specific equipment implementation.

This document defines two groups of linear optical parameters.

Mandatory Linear Optical Parameters
This set includes Optical Signal Power and the OSNR with associated variances. It represents the minimum set to asses the feasibility of an optical path. This set will be encoded using mandatory sub-TLVs.
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 optional sub-TLVs.

Separation between mandatory and optional parameters 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 the full set of optical path parameters. With this classification, the lightpath signaling still continues to work although with a less accurate evaluation.

The choice of the 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.



 TOC 

7.1.  Optical Parameter sub-TLV overview

Each optical parameter will be encoded using the following format:



     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              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Optical Parameter Value                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Optical Parameter Variance                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 4 

Type: sub_TLV type > 1.

Flags: mandatory or optional according to each parameter classification, variable.

Length: total length of the Sub-TLV including header in octets (8 octets or 12 octets depending if the optical parameter has the variance value associated).

Value associated with the optical parameter.

Variance: the error estimation for optical parameter value calculation. Depending on the length value may not be present.



 TOC 

7.2.  Mandatory Linear Optical Parameters sub-TLVs

The Sub-TLVs encode the following optical parameters of a channel (wavelength) measured at the node egress interface. Flags are: mandatory, variable.



 TOC 

7.2.1.  Optical Power

Type = 2.

Value: 32bit IEEE floating point number. Measurement Unit: dBm.



 TOC 

7.2.2.  Optical Signal to Noise Ratio

Type = 3.

Value: 32bit IEEE floating point number. Measurement Unit: dB.



 TOC 

7.3.  Optional Linear Optical Parameters sub-TLVs

The Sub-TLVs encode the following optical parameters of a channel (wavelength) measured at the node egress interface. Flags are: optional, variable.



 TOC 

7.3.1.  Chromatic Dispersion (CD)

Type = 4.

Value: 32bit IEEE floating point number. Measurement Unit: ps/nm.



 TOC 

7.3.2.  Polarization Mode Dispersion (PMD)

Type = 5.

Value: 32bit IEEE floating point number. Measurement Unit: ps.



 TOC 

7.3.3.  Cross-Talk (XT)

Type = 6.

Value: 32bit IEEE floating point number. Measurement Unit: dB.



 TOC 

8.  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, 24 bytes for the Mandatory Linear Optical Path parameters plus 36 bytes for the Optional Linear Optical Parameter sub-TLV. Total is 48 bytes for each wavelength by just considering mandatory sub-TLVs and 84 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 1536 to 2688 bytes.

A possible option is to let the application layer requesting the lightpath setup to decide how many wavelengths to signal according to the MTU available. For example, having an MTU of 1500 bytes the application layer might signal only 10 wavelengths with the full set of parameters taking up 840 bytes, or it might decide to signal 20 wavelengths with just the mandatory parameters. Note that, according to procedure described within Section 3 (Optical Path Impairment Validation), the message size may decrease as long as the Path message pass through transit nodes.

A second solution proposed here implements 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 Object with a new Class Type (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 additional information on the "fragment id" and on the requested policy for the channel selection at the egress 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              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 5 



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              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 6 

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

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



 TOC 

9.  Backward Compatibility

The TLV usage as defined by [RFC5420] (Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, “Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE),” February 2009.) 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 egress node. If a transit node does not support the extensions the collected information is unreliable and the Path request MUST be rejected.



 TOC 

10.  Error management

No additional error code is introduced to manage requests failures; the behavior defined in [RFC5420] (Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, “Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE),” February 2009.) applies to the management of the LSP_REQUIRED_ATTRIBUTES Object.



 TOC 

11.  Acknowledgments



 TOC 

12.  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
   Cisco Systems
   via Philips 12
   Monza  20052, Italy

   Email: ggalimbe@cisco.com

   Alberto Tanzi
   Cisco Systems
   via Philips 12
   Monza  20052, Italy

   Email: atanzi@cisco.com

   Domenico La Fauci
   Cisco Systems
   via Philips 12
   Monza  20052, Italy

   Email: dlafauci@cisco.com

   Elio Salvadori
   CREATE-NET
   via alla Cascata 56 C, Povo
   Trento  38100, Italy

   Email: elio.salvadori@create-net.org

   Chava Vijaya Saradhi
   CREATE-NET
   via alla Cascata 56 C, Povo
   Trento  38100, Italy

   Email: saradhi.chava@create-net.org



 TOC 

13.  IANA Considerations

This memo needs the following request to IANA

TLV (see Figure 1 in Section 5 (Information Encoding ))

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

All drafts are required to have an IANA considerations section (see the update of RFC 2434 (Devarapalli, V. and P. Eronen, “Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE),” June 2008.) [RFC5266] 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.



 TOC 

14.  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.



 TOC 

15.  References



 TOC 

15.1. Normative References

[ITU.G680] International Telecommunications Union, “Physical transfer functions of optical network elements,” ITU-T Recommendation G.680, July 2007.
[ITU.G709] International Telecommunications Union, “Interface for the Optical Transport Network (OTN),” ITU-T Recommendation G.709, March 2003.
[ITU.G975.1] International Telecommunications Union, “Forward Error Correction for high bit rate DWDM Submarine Systems,” ITU-T Recommendation G.975, February 2004.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” RFC 2205, September 1997 (TXT, HTML, XML).
[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 (TXT).
[RFC3471] Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description,” RFC 3471, January 2003 (TXT).
[RFC3473] Berger, L., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions,” RFC 3473, January 2003 (TXT).
[RFC4328] Papadimitriou, D., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control,” RFC 4328, January 2006 (TXT).
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, “Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE),” RFC 5420, February 2009 (TXT).


 TOC 

15.2. Informative References

[I-D.bernstein-wson-impairment-info] Lee, Y., Bernstein, G., Systems, C., Martinelli, G., and A. Zanardi, “Information Model for Impaired Optical Path Validation,” draft-bernstein-wson-impairment-info-03 (work in progress), October 2010 (TXT).
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels] Otani, T., Rabbat, R., Shiba, S., Guo, H., Miyazaki, K., Caviglia, D., Li, D., and T. Tsuritani, “Generalized Labels for Lambda-Switching Capable Label Switching Routers,” draft-ietf-ccamp-gmpls-g-694-lambda-labels-07 (work in progress), April 2010 (TXT).
[I-D.ietf-ccamp-rwa-wson-framework] Bernstein, G., Lee, Y., and W. Imajuku, “Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON),” draft-ietf-ccamp-rwa-wson-framework-07 (work in progress), October 2010 (TXT).
[I-D.ietf-ccamp-wson-impairments] Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M., Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan, M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D. Caviglia, “A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments,” draft-ietf-ccamp-wson-impairments-04 (work in progress), October 2010 (TXT).
[I-D.ietf-ccamp-wson-signaling] Bernstein, G., Andriolli, N., Giorgetti, A., Guo, L., Harai, H., Ji, Y., King, D., Lee, Y., and S. Xu, “Signaling Extensions for Wavelength Switched Optical Networks,” draft-ietf-ccamp-wson-signaling-00 (work in progress), October 2010 (TXT).
[RFC3945] Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” RFC 3945, October 2004 (TXT).
[RFC4054] Strand, J. and A. Chiu, “Impairments and Other Constraints on Optical Layer Routing,” RFC 4054, May 2005 (TXT).
[RFC5266] Devarapalli, V. and P. Eronen, “Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE),” BCP 136, RFC 5266, June 2008 (TXT).


 TOC 

Authors' Addresses

  Giovanni Martinelli (editor)
  Cisco Systems
  via Philips 12
  Monza 20052
  Italy
Email:  giomarti@cisco.com
  
  Andrea Zanardi (editor)
  CREATE-NET
  via alla Cascata 56 C, Povo
  Trento 38100
  Italy
Email:  andrea.zanardi@create-net.org