Hi CCAMP WG,

We are finishing up both generic encoding (draft-ietf-ccamp-general-constraint-encode) and WSON encoding.

One of the pending issues is if we need to advertise different priorities levels for available labels and shared backup labels (to be able to preempt lower priority LSP when high priority LSP is setup). This requirement was raised by Rajan. The authors feel this is a legitimate requirement and proposed the following encoding changes to the current available Labels sub-TLV (section 1.1) and shared backup labels sub-TLV (section 1.2). Please let us know if you object to this. Otherwise, we will add this encoding in the upcoming revision. Please also provide your comment to this encoding proposal if you have any questions.

Thanks.

Young & Greg

-----suggested encoding-------------------------------------------------------------------------------------------------------------------------------------------------

1.1. Available Labels Sub-TLV

To indicate the labels available for use on a link the Available Labels sub-TLV consists of a single variable length label set field as follows:

   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

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |A| Reserved    | Priority Flags|        Reserved               |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                          Label Set Field                    |

  :                                                            :

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where

A (Availability bit) = 1 or 0 indicates that the labels listed in the following label set field are available or not available, respectively, for use at a given priority level as indicated by the Priority Flags.

Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 corresponds to priority level 7. If a bit is set then the labels in the label set field are available or not available as indicated by the A bit for use at that particular priority level.

Note that Label Set Field is defined in Section 3.2.

1.2. Shared Backup Labels Sub-TLV

To indicate the labels available for shared backup use on a link the Shared Backup Labels sub-TLV consists of a single variable length label set field as follows:

   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

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |A| Reserved    | Priority Flags|        Reserved                |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                    Label Set Field                          |

  :                                                            :

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where

A (Availability bit) = 1 or 0 indicates that the labels listed in the following label set field are available or not available, respectively, for use at a given priority level as indicated by the Priority Flags.

Priority Flags: Bit 8 corresponds to priority level 0 and bit 15 corresponds to priority level 7. If a bit is set then the labels in the label set field are available or not available as indicated by the A bit for use at that particular priority level.

Greg,

Want to go back to issue #1 one more time.   If  LSP pre-emption is a requirement (which I think it should be), then we do not have sufficient information in BW advertisement to compute path for a higher priority LSP.    The unreserved BW <at> 8 priorities plus  Available Labels don’t provide enough information to perform RWA.

On #2,  are you saying that it is sufficient to imply  SC = LSC   without explicitly having a field for SC in Available Labels sub-TLV?

Thanks

Rajan

Hi Rajan, see below.
Greg
On 12/13/2011 5:43 PM, Rajan Rao wrote:

Greg,

Sure,  using unreserved BW  we can address  #1.    I assume the value carried in unreserved BW is still  in Bytes/sec (& not lambda count).    This point was not clear to me from the drafts.

--> We are not modifying earlier GMPLS RFCs such as RFC4202 and RFC4203. Although, I was a co-author of these, but disagree with some of the choices made. There are aspects of these documents that don't make much sense for TDM or optical networks.

My point #2 is more related to MRN case.   If one were to use IACD as in RFC6001,  what is the SC & encoding to use as BW advertisement is not telling me this?

--> The switching capability would be "lambda switch capable" per RFC4202, 4203. We don't change any of this for WSONs.

Thanks

Rajan

Hi Rajan, in RFC4202 section 2.4.4 states: "The additional information includes Reservable Bandwidth per priority, which specifies the bandwidth of an LSP that could be supported by the interface at a given priority number."
Section "3.10. Interface on a OXC with Internal DWDM That Is Transparent to Bit-Rate and Framing" then gives an example of how to encode this information:
"The following is an example of an interface switching capability
   descriptor on an OXC with internal DWDM that is transparent to bit-
   rate and framing:

      Interface Switching Capability Descriptor:
         Interface Switching Capability = LSC
         Encoding = Lambda (photonic)
         Max LSP Bandwidth = Determined by optical technology limits"

Hence I don't think there is a conflict with RFC4202 or RFC4203.  RFC3630 section 2.5.8 defines the "Unreserved Bandwidth" sub-TLV for MPLS-TE which you can use. There was no requests for the feature of priority designation in the available labels or shared backup labels (section 7.1 of http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-13).

Is there some specific functionality you're looking for?

Greg
On 12/13/2011 11:59 AM, Rajan Rao wrote:

Young & Greg,

Please see response below.

Thanks

Rajan

Hi Rajan,

Here’s our response to your questions. Please see-in line. Thanks.

Young& Greg

Hi Authors,

Wanted to follow up on the comment I made during IETF meeting in Taipei.   This refers to gaps in current WSON WG docs.   I see following capabilities not addressed in the drafts:

1)      Different Priorities levels for available labels:   current drafts do not provide a way to advertise Available labels at different priorities.  Not sure if this was left out intentionally.

YOUNG/Greg>> We are not sure if there is a clear requirement to assign different priorities (wavelength preference) levels to labels in WSON via routing. There are mechanisms already for specifying prefered labels in GMPLS signaling.  In addition there are capabilities proposed in the WSON signaling draft that can serve this function more specifically for WSONs.  Note that this is a different concept from restoration or traffic priority for an LSP which is generally supported under GMPLS/MPLS.

[Rajan]  As far as requirement goes,  I would refer to RFC 4202 (section 2.4.4).

The issue I see in the current BW adv model is the following:

(a)    Since Labels (BW) advertised don’t have priorities associated,  one can’t  set up prioritized  Lambda-LSPs.  

(b)   If I want high priority lambda-LSP(s) to  pre-empt a low priority lambda-LSP(s),  I don’t have a way to do it with the current scheme.   This means I can’t have restoration support for HighPriority LSPs unless I reserve some waves without use.

The current BW adv model is kind of flat & prevents  above functionalities which I think are important in transport networks.

2)      Switching capability:   current drafts do not provide a way to identify switching cap as it is non ISCD based.   Going forward we will need  SC info as there is going to be FlexGrid capable links possible on the same node.  It is also possible that same link may support both fixed/flexible types of switching.

Any reason why we can’t use ISCD here?

YOUNG/Greg>> We believe that Flex grid should be addressed separately. First it is not CCAMP item yet and more importantly, it is beyond the scope of the current WSON. WSON only deals with “fixed” grid per se. It is not a good practice to convolute the existing scope with potential future capabilities such as flex grid. As Taipei meeting discussed this issue a bit, it will take a while for data plane work in ITU-T to settle in and it will take much efforts to identify first the overarching requirements first before getting into solutions.

[Rajan]  Agree on addressing FlexGrid separately.  

We are following  RFC 4202 definition of Switching Cap for PSC, TDM & OTN.     Wonder why  are not using  LSC already defined in the RFC? 

 In addition,  the IACD  approach  defined in  RFC 6001 for MLN/MRN is based on multiple switching Cap info.  How can we address MLN/MRN without SC info?

Will be happy to join and contribute to the draft.  Please let me know.

Thanks

Rajan