Re: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

[Khuzema Pithewan <[e-mail]>]

Hi Fei,

Thank You for your comments. Please see the response for your both the comments.


>                    Comment1: ST means Signal Type (Not Swithcing/Terminating). It is as defined in RFC 4328 and extended in section 4 of this draft. We will further clarify this next version.

>                    Comment2:   G-PID usage as you have suggested definitely works.  we stayed away from using G_PID in label due to its presence in generalized label request already.  The thought here is the time slot info is pertaining to a particular stage in the multiplexing hierarchy. The order of the stage in the label is identified by the order in which the label info is appearing in the multi-stage label. Since the number of time slots will depend on parent signal type and time slot group, we have kept length field for easy decoding.

Hope this clarifies

Best Regards
Khuzema





From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, March 17, 2011 8:38 AM
To: Rajan Rao
Cc: [e-mail]; [e-mail]
Subject: Re: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt


Dear Rajan

I have read the draft, here are some comments, please consider:

5.1 Multi-stage Label

You defined the Multi-stage label as 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num MUX Stages|  OD(T)Uk (ST) |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-1)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              . . .                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-n)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Below is the Tributary Slot Info
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ODUj (ST)  | T |  Length   |      Tributary Port Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Variable Length Bit Map (4-byte boundary aligned)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Comments 1：I did not see the explanation of ODUK(ST) or ODUj(ST), S meaning Switching capability and T means Terminating capability?

Comments 2: I agree with you that there are some scenarios that needs non-FA scheme based multi-stage , citing from your documents
         ( Note: Multi-stage Label is NOT intended to facilitate the creation of  FA-LSP or Hierarchical LSP. It is basically used to
           eliminate the need for FA-LSP in some obvious scenarios.)

Be glad to see that you consider the information of multi-stage labels, but maybe you can redefine this label format as below,
which can improve the encoding efficiency without losing the information about multi-stage labels.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | GPID                          | T |         TPN               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Bitmap  .........                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here the GPID are following the same usage defined in section 5.5.2.1 of the document
 http://tools.ietf.org/html/draft-ashok-ccamp-gmpls-ospf-g709-03 and the numbers of T/TPN/bitmap depends on the numbers of multi-stage.

The encoding of Generalized Label is as follows:

   Case-1: ODUk mapping into OTUk
   GPID = ODUk
   T and TPN SHOULD be set to zero; bitmap is not required.

   Case-2: ODUj mux into ODUk
   GPID=ODUk-ODUj
   TPN = <specified as per Section 5>
   BitMap = <TSs reserved for ODUj are set to 1>

   Case-3 ODUh mux into ODUj into ODUk
   GPID=ODUk-ODUj-ODUh.
   The fit T/TPN/bitmap sequence indicates the usage of ODUk-ODUj;
and the second T/TPN/bitmap sequence indicates the usage of ODUj-ODUh.

Apparently, this is the unified encoding format suitable for single-stage and multi-stage multiplexing.

According to the example you provided in section 9 (ODU0-ODU2-ODU3 multiplexing between node B and node C)

   +-----+             +-----+             +-----+             +-----+
   | OTN |             | OTN |             | OTN |             | OTN |
   | SW  |<-OTU2(1.25)>| SW  |<-OTU3(2.5)->| SW  |<-OTU2(1.25)->| SW  |
   |  A  |             |  B  |             |  C  |             |  D  |
   +-----+             +-----+             +-----+             +-----+

The label format between B and C is
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | GPID=ODU3-ODU2-ODU0          |T=2|         TPN=1…4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Bitmap=ODU3-ODU2             |T=1|         TPN=1…8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Bitmap=ODU2-ODU0|      padding (0)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Just my two cents, compared to the old solution, this one is more efficient without losing any information.

Best regards

Fei
*********************************************************************
Fei Zhang Ph.D.
Add:System Architecture Dept./ZTE Central R&D Institute/R&D/ZTE
Tel:[phone]
Mobile:[phone]
Mail: [e-mail]
*********************************************************************



Rajan Rao <[e-mail]>
发件人:  [e-mail]

2011-03-15 09:17

收件人

"[e-mail]" <[e-mail]>

抄送

主题

Re: [CCAMP] I-D        Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt







Hi,

We have submitted updates to the following draft. Please review & comment.

http://tools.ietf.org/html/draft-khuzema-ccamp-gmpls-signaling-g709-01


Thanks
Authors


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, March 14, 2011 12:45 PM
To: [e-mail]
Subject: I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

                Title           : Signaling Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks
                Author(s)       : K. Pithewan, et al.
                Filename        : draft-khuzema-ccamp-gmpls-signaling-g709-01.txt
                Pages           : 21
                Date            : 2011-03-14

As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is also specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp