[CCAMP] Proposed revision of section 4.2-4.4 wson-signaling (WAS: Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08)

[Lou Berger <[e-mail]>]

All,

I'm sending the  revised section to increase the likelihood that the
text will be reviewed.  Please take a look and comment.  Again, the
objective is to document the resolution of the issue discussed/resolved
in http://www.ietf.org/mail-archive/web/ccamp/current/msg16366.html and
I'd be surprised if I didn't miss something.

Lou

On 9/9/2014 9:25 PM, Lou Berger wrote:
> Young/Authors/WG
>
> I've done a fairly significant revision of section 4.2-4.4 to align the
> text with my understanding of the discussion. No additional technical
> changes are intended. The text should now use [RSVP-RO] to carry the
> information from those sections. I did the change by editing the most
> recently published rev (-08). I'll send the authors document versions.
> Here's what wdiff says the changes are. Given their scope, I'd be amazed
> if I didn't miss something.
> ...


    4.2. WSON Processing HOP Attribute TLV

   Section 3.2. provided the requirements for signaling to indicate to
   a particular node along an LSP what type of processing to perform on
   an optical signal or how to configure that node to accept or
   transmit an optical signal with particular attributes.

   To target a specific node, this section defines a WSON Processing
   HOP Attribute TLV. This TLV is encoded as an attributes TLV, see
   [RFC520]. The TLV is carried in the ERO and RRO LSP Attribute
   Subobjects, and processed according to the procedures, defined in
   [RSVP-RO]. The type value of the WSON Processing HOP Attribute TLV
   is TBD by IANA.

   The WSON Processing HOP Attribute TLV carries one or more sub-TLVs
   with 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      |   Length      |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   //                            Value                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         The identifier of the sub-TLV.

      Length

         Indicates the total length of the sub-TLV in octets.  That is, the
         combined length of the Type, Length, and Value fields, i.e.,
         four plus the length of the Value field in octets.

         The entire sub-TLV MUST be padded with zeros to ensure four-octet
         alignment of the sub-TLV.  The Length field does not include any
         padding.

      Value

         Zero or more octets of data carried in the sub-TLV.

   
   Sub-TLV ordering is significant and MUST be preserved. Error
   processing follows [RSVP-RO].

    The following sub-TLV types are defined in this document:

   Sub-TLV Name        Type    Length
   --------------------------------------------------------------
   ResourceBlockInfo    1      variable
   WavelengthSelection  2        1 (3 octets padding )

   The TLV can be represented in Reduced Backus-Naur Form (RBNF)
   [RFC5511] syntax as:

   <WSON Processing HOP Attribute> ::= < ResourceBlockInfo>
   [<ResourceBlockInfo>] [<WavelengthSelection>]

    4.2.1. ResourceBlockInfo Sub-TLV

   The format of the ResourceBlockInfo sub-TLV value field is defined
   in Section 4 of [WSON-Encode]. It a list of available Optical
Interface Classes and
   processing capabilities.

   At least one ResourceBlockInfo sub-TLV MUST be present in the
   WSON_Processing HOP Attribute TLV. No more than two
   ResourceBlockInfo sub-TLVs SHOULD be present. Any present
   ResourceBlockInfo sub-TLVs MUST be processed in the order received,
   and extra (unprocessed) SHOULD be ignored.

   The ResourceBlockInfo field contains several information elements as
defined by
   [WSON-Encode]. The following rules apply to the sub-TLV:

   o  RB Set Field can carry one or more RB Identifier. Only the first
      of RB Identifier listed in the RB Set Field SHALL be processed,
      any others SHOULD be ignored.

   o  In the case of unidirectional LSPs, only one ResourceBlockInfo
      sub-TLV SHALL be processed and the I and O bits can be safely ignored.

   o  In the case of a bidirectional LSP, there MUST either be either:
     (a) only one ResourceBlockInfo sub-TLV present in a WSON_Processing  
         HOP Attribute TLV, and the bits I and O both set to 1, or
     (b) two ResourceBlockInfo sub-TLVs present, one of which has only
the I
         bit set and the other of which has only the O bit set.

   o  The rest of information carried within the ResourceBlockInfo sub-TLV
      includes Optical Interface Class List, Input Bit Rate List and
      Processing Capability List. These lists MAY contain one or more
      elements. These elements apply equally to both bidirectional
      and unidirectional LSPs.
 
   Any violation of these rules detected by a transit or egress node
   SHALL be treated as an error and be processed per [RSVP-RO].

   A ResourceBlockInfo sub-TLV can be constructed by a node and added
   to a ERO_HOP_ATTRIBUTE subobject in order to be processed by
   downstream nodes (transit and egress). As defined in [RSVP-RO], the
   R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic
   defined in [RFC5420] and SHOULD be set accordingly.

   Once a node properly parses a ResourceBlockInfo Sub-TLV received in
   an ERO_HOP_ATTRIBUTE subobject (according to the rules stated above
   and in [RSVP-RO]), the node allocates the indicated resources, e.g.,
   the selected regeneration pool, for the LSP. In addition, the node
   SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE subobject
   with the WSON Processing HOP Attribute TLV (and its sub-
   TLVs)indicating the utilized resources. ResourceBlockInfo Sub-TLVs
   carried in a RRO_HOP_ATTRIBUTE subobject are subject to [RSVP-RO]
   and standard RRO processing, see [RFC3209].

    4.2.2. WavelengthSelection Sub-TLV

   Routing + Distributed Wavelength Assignment (R+DWA) is one of the
   options defined by the [RFC6163]. The output from the routing
   function will be a path but the wavelength will be selected on a
   hop-by-hop basis.

   As discussed in [HZang00], a number of different wavelength
   assignment algorithms may be employed. In addition as discussed in
   [RFC6163] the wavelength assignment can be either for a
   unidirectional lightpath or for a bidirectional lightpath
   constrained to use the same lambda in both directions.

   In order to indicate wavelength assignment directionality and
   wavelength assignment method, the Wavelength Selection, or
   WavelengthSelection, sub-TLV is defined to be carried in the WSON
   Processing HOP Attribute TLV defined above.
  
   The WavlengthSelection sub-TLV value field is defined as:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |W|  WA Method  |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Where:

   W (1 bit): 0 denotes requiring the same wavelength in both
   directions, 1 denotes that different wavelengths on both directions
   are allowed.

   Wavelength Assignment (WA) Method (7 bits):

   0 - unspecified (any); This does not constrain the WA method used by
   a specific node. This value is implied when the WavelengthSelection
   Sub-TLV is absent.


   1 - First-Fit. All the wavelengths are numbered and this WA method
   chooses the available wavelength with the lowest index.

   2 - Random. This WA method chooses an available wavelength randomly.

   3 - Least-Loaded (multi-fiber). This WA method selects the
   wavelength that has the largest residual capacity on the most loaded
   link along the route. This method is used in multi-fiber networks.
   If used in single-fiber networks, it is equivalent to the FF WA
   method.

   4- 127: Unassigned.

   The processing rules of this TLV are as follows:

   If a receiving node does not support the attribute(s), its behaviors
   are specified below:

   - W bit not supported: a PathErr MUST be generated with the Error
     Code "Routing Problem" (24) with error sub-code "Unsupported
     WavelengthSelection Symmetry value" (value to be assigned by IANA,
     suggested value: 107).

   - WA method not supported: a PathErr MUST be generated with the
     Error Code "Routing Problem" (24) with error sub-code "Unsupported
     Wavelength Assignment value" (value to be assigned by IANA,
     suggested value: 108).

   A WavelengthSelection sub-TLV can be constructed by a node and added
   to a ERO_HOP_ATTRIBUTE subobject in order to be processed by downstream
   nodes (transit and egress). As defined in [RSVP-RO], the R bit reflects
   the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in
   [RFC5420] and SHOULD be set accordingly.

   Once a node properly parses the WavelengthSelection Sub-TLV received
   in an ERO_HOP_ATTRIBUTE subobject, the node use the indicated
   wavelength assignment method (at that hop) for the LSP. In addition,
   the node SHOULD report compliance by adding a RRO_HOP_ATTRIBUTE
   subobject with the WSON Processing HOP Attribute TLV (and its
   sub-TLVs) indicated the utilized method. WavelengthSelection
   Sub-TLVs carried in a RRO_HOP_ATTRIBUTE subobject are subject to
   [RSVP-RO] and standard RRO processing, see [RFC3209].