[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                       G. Martinelli, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                         A. Zanardi, Ed.
Expires: August 25, 2008                                      CREATE-NET
                                                       February 22, 2008


GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup
          draft-martinelli-ccamp-optical-imp-signaling-01.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 August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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



Martinelli & Zanardi     Expires August 25, 2008                [Page 1]


Internet-Draft        Optical Impairment Signaling         February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Optical Path Validation Procedure  . . . . . . . . . . . . . .  4
   4.  Physical Parameter Classification and top level TLV  . . . . .  5
   5.  Optical Service Parameters sub-TLV . . . . . . . . . . . . . .  7
     5.1.  Forward Error Correction (FEC) . . . . . . . . . . . . . .  8
     5.2.  Modulation Format  . . . . . . . . . . . . . . . . . . . .  9
   6.  Optical Path Parameters sub-TLV(s) . . . . . . . . . . . . . .  9
     6.1.  Optical Parameter sub-TLV overview . . . . . . . . . . . . 10
     6.2.  Mandatory Linear Optical Parameters sub-TLVs . . . . . . . 10
       6.2.1.  Optical Power  . . . . . . . . . . . . . . . . . . . . 11
       6.2.2.  Optical Signal to Noise Ratio  . . . . . . . . . . . . 11
     6.3.  Optional Linear Optical Parameters sub-TLVs  . . . . . . . 11
       6.3.1.  Chromatic Dispersion (CD)  . . . . . . . . . . . . . . 11
       6.3.2.  Polarization Mode Dispersion (PMD) . . . . . . . . . . 11
       6.3.3.  Cross-Talk (XT)  . . . . . . . . . . . . . . . . . . . 11
   7.  Message Fragmentation  . . . . . . . . . . . . . . . . . . . . 11
   8.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 14
   9.  Error management . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     14.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19





















Martinelli & Zanardi     Expires August 25, 2008                [Page 2]


Internet-Draft        Optical Impairment Signaling         February 2008


1.  Introduction

   The current Generalized Multi-Protocol Label Switching (GMPLS)
   specification [RFC3945] and the signaling related documents
   ([RFC3471], [RFC3473], [RFC4328]) support optical interfaces with
   different switching capability to setup a lightpath while [RFC4054]
   defines the impairments to be considered in optical routing.
   [I-D.bernstein-ccamp-wavelength-switched], defines a framework
   identifying the key components and issues pertaining to wavelength
   switched optical networks (WSON).
   [I-D.otani-ccamp-gmpls-lambda-labels] proposes a global semantic for
   wavelength generalized labels taking into account lightpath 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 there is physical
   connectivity (fibers, wavelengths, and nodes) between the ingress and
   egress nodes, there is no guarantee that the optical signal (light)
   reaches the Egress node with acceptable signal quality, for example
   in terms of BER/OSNR/Q-factor limit.  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.  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].

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

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

   o  The optical service parameters describe the requested signal type,
      are related to the characteristics of the transponder at ingress
      node and hence are not changed at transit nodes.

   o  The optical path parameters describe the signal characteristics
      evolution along the path from ingress node to egress 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 expandable linear impairments such as



Martinelli & Zanardi     Expires August 25, 2008                [Page 3]


Internet-Draft        Optical Impairment Signaling         February 2008


      chromatic dispersion (CD), polarization mode dispersion (PMD),
      crosstalk, etc.  The optional parameters can be used to evaluate
      the feasibility of a lightpath 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 [RFC2119].

   In additions this document will use terminology from [RFC2205],
   [RFC3209], [RFC4054], and [I-D.bernstein-ccamp-wavelength-switched].


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:

   o  The ingress 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.

   o  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).

   o  The egress 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.

   o  Transit nodes process the Resv message cross-connecting the
      selected wavelength in incoming and outgoing interfaces
      (wavelength continuity constraint).

   o  The ingress node cross-connects the selected wavelength to a local
      transponder supporting the selected signal type (FEC and
      modulation format).

   This procedure forces the meeting of the wavelength continuity
   constraint: the final effect of pruning wavelengths (e.g. removing



Martinelli & Zanardi     Expires August 25, 2008                [Page 4]


Internet-Draft        Optical Impairment Signaling         February 2008


   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.

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

   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

   RSVP/RSVP-TE requires the following additional information in order
   to be aware of optical impairments and setup optically feasible
   lightpaths:

   o  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 egress node of an
      LSP has to know a certain set of specific optical parameters
      related to the transmitting interface.  Section 5 reports details
      of these parameters and their encoding.

   o  Optical Path Parameters.
      These attributes are required to support transmission of physical
      impairment parameters for the optical path feasibility evaluation.
      Details are presented in Section 6.

   This document defines how to encode the above information through new
   TLVs according to [RFC4420].

   The proposed encoding scheme for the optical parameters defines a TLV



Martinelli & Zanardi     Expires August 25, 2008                [Page 5]


Internet-Draft        Optical Impairment Signaling         February 2008


   (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

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

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

   o  Wavelength ID: wavelength label identifier according to
      [I-D.otani-ccamp-gmpls-lambda-labels].

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

   The TLVs wavelength ID value must be consistent with the presence of
   LABEL_SET objects and its actions as defined within [RFC3471] and
   [RFC3473].

   The Sub-TLV format is defined in the next picture









Martinelli & Zanardi     Expires August 25, 2008                [Page 6]


Internet-Draft        Optical Impairment Signaling         February 2008


   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: Value field length in bytes

      Value: variable length Sub-TLV content

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

   o  Constant sub-TLVs are forwarded as-is.

   o  Mandatory non constant sub-TLVs MUST be updated with the local
      parameter value, if the parameter is not managed by the node, it
      MUST reject the request with a failure.

   o  Optional non constant sub-TLVs MUST be updated with the local
      parameter value, if the parameter is not managed by the node, it
      MUST silently drop it from the TLV (the value would be
      inaccurate).


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



Martinelli & Zanardi     Expires August 25, 2008                [Page 7]


Internet-Draft        Optical Impairment Signaling         February 2008


   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: length of the sub-TLV value in bytes

      FEC: supported Forward Error Correction Modes (see Section 5.1

      Mod Format: supported modulation formats (see Section 5.2)
      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.

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])





Martinelli & Zanardi     Expires August 25, 2008                [Page 8]


Internet-Draft        Optical Impairment Signaling         February 2008


      2-9: super-FEC according to sub clauses from I.2 to I.9 of
      [ITU.G975.1]

   Values with the format 1bbbbbbbbbbbbbbb are left to represent vendor
   specific or proprietary FEC encoding.

5.2.  Modulation Format

   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.


6.  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.).

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



Martinelli & Zanardi     Expires August 25, 2008                [Page 9]


Internet-Draft        Optical Impairment Signaling         February 2008


   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] and
   provide sufficient accuracy for the linear impairments evaluation.

6.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: 4 octets or 8 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.

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



Martinelli & Zanardi     Expires August 25, 2008               [Page 10]


Internet-Draft        Optical Impairment Signaling         February 2008


6.2.1.  Optical Power

   Type = 2.

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

6.2.2.  Optical Signal to Noise Ratio

   Type = 3.

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

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

6.3.1.  Chromatic Dispersion (CD)

   Type = 4.

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

6.3.2.  Polarization Mode Dispersion (PMD)

   Type = 5.

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

6.3.3.  Cross-Talk (XT)

   Type = 6.

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


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, 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



Martinelli & Zanardi     Expires August 25, 2008               [Page 11]


Internet-Draft        Optical Impairment Signaling         February 2008


   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, 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 [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 [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

















Martinelli & Zanardi     Expires August 25, 2008               [Page 12]


Internet-Draft        Optical Impairment Signaling         February 2008


       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:

   o   TotalNo: 8 bit integer representing the total number of Path
       messages issued by the ingress node to setup a single lightpath.
       When this values is equals to 1 all the other fields MUST be
       ignored.

   o   MsgId: 8 bit integer representing the sequential number of a
       single Path request.  Its value must be between 1 and TotalNo,
       both inclusive.

   o   P: Policy the egress 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 arrives, wait for any message
               within the specified Timeout.

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

       The egress 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 upstream nodes.



Martinelli & Zanardi     Expires August 25, 2008               [Page 13]


Internet-Draft        Optical Impairment Signaling         February 2008


   o   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] 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.


9.  Error management

   No additional error code is introduced to manage requests failures;
   the behavior defined in [RFC4420] applies to the management of the
   LSP_REQUIRED_ATTRIBUTES Object.


10.  Acknowledgments


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):












Martinelli & Zanardi     Expires August 25, 2008               [Page 14]


Internet-Draft        Optical Impairment Signaling         February 2008


   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 alla Cascata 56 C, Povo            via alla Cascata 56 C, 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 alla Cascata 56 C, Povo
   Trento  38100
   Italy

   Email: saradhi.chava@create-net.org





12.  IANA Considerations

   This memo needs the following request to IANA

      TLV (see Figure 1 in Section 4)

      New class type for sender template (see Section 7)

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]



Martinelli & Zanardi     Expires August 25, 2008               [Page 15]


Internet-Draft        Optical Impairment Signaling         February 2008


   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].
   GMPLS security is described in section 11 of [RFC3471] and refers to
   [RFC3209] for RSVP-TE.


14.  References

14.1.  Normative References

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

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

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4328]  Papadimitriou, D., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Extensions for G.709 Optical



Martinelli & Zanardi     Expires August 25, 2008               [Page 16]


Internet-Draft        Optical Impairment Signaling         February 2008


              Transport Networks Control", RFC 4328, January 2006.

   [RFC4420]  Farrel, A., Papadimitriou, D., Vasseur, J., and A.
              Ayyangar, "Encoding of Attributes for Multiprotocol Label
              Switching (MPLS) Label Switched Path (LSP) Establishment
              Using Resource ReserVation Protocol-Traffic Engineering
              (RSVP-TE)", RFC 4420, February 2006.

14.2.  Informative References

   [I-D.bernstein-ccamp-wavelength-switched]
              Bernstein, G., "Framework for GMPLS and PCE Control of
              Wavelength Switched Optical  Networks",
              draft-bernstein-ccamp-wavelength-switched-03 (work in
              progress), February 2008.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-08 (work in
              progress), October 2007.

   [I-D.otani-ccamp-gmpls-lambda-labels]
              Otani, T., Guo, H., Miyazaki, K., Caviglia, D., and Z.
              Ali, "Document:
              draft-otani-ccamp-gmpls-lambda-labels-01.txt",
              draft-otani-ccamp-gmpls-lambda-labels-01 (work in
              progress), November 2007.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4054]  Strand, J. and A. Chiu, "Impairments and Other Constraints
              on Optical Layer Routing", RFC 4054, May 2005.


Authors' Addresses

   Giovanni Martinelli (editor)
   Cisco Systems
   via Philips 12
   Monza  20052
   Italy

   Email: giomarti@cisco.com






Martinelli & Zanardi     Expires August 25, 2008               [Page 17]


Internet-Draft        Optical Impairment Signaling         February 2008


   Andrea Zanardi (editor)
   CREATE-NET
   via alla Cascata 56 C, Povo
   Trento  38100
   Italy

   Email: andrea.zanardi@create-net.org












































Martinelli & Zanardi     Expires August 25, 2008               [Page 18]


Internet-Draft        Optical Impairment Signaling         February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Martinelli & Zanardi     Expires August 25, 2008               [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/