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

From: Rajan Rao <[email-masked]>
Date: Mon, 14 Mar 2011 18:17:04 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 14, 2011 12:45 PM
To: [email-masked]
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.

---

From: [email-masked]
Date: Thu, 17 Mar 2011 11:08:07 +0800

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:86-025-52877612
Mobile:86-13914483568
Mail: [email-masked]
*********************************************************************

Rajan Rao <[email-masked]> 
发件人:  [email-masked]
2011-03-15 09:17

收件人
"[email-masked]" <[email-masked]>
抄送

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

Hi,

Thanks
Authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On Behalf Of [email-masked]
Sent: Monday, March 14, 2011 12:45 PM
To: [email-masked]
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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 16 Mar 2011 22:42:52 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 17, 2011 8:38 AM
To: Rajan Rao
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Dear Rajan

5.1 Multi-stage Label

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

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.

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)

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

Best regards

Fei

2011-03-15 09:17

收件人

抄送

主题

Hi,

Thanks
Authors

---

From: [email-masked]
Date: Thu, 17 Mar 2011 14:00:24 +0800

Hi Khuzema
.  we stayed away from using G_PID in label due to its presence in 
generalized label request already. 

Fei: the G_PID used in generalized label request is different from here.

    The format of a Generalized Label Request object is:(cited from 
RFC3471)
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LSP Enc. Type |Switching Type |             G-PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here GPID is used to represent an identifier of the payload carried by an 
LSP, i.e., an identifier of the client layer of that LSP. 

For example:

   ODU3-ODU2-ODU1-ODU0                 ODU3-ODU2-ODU1-ODU0
        A===================================B
                 OTU3 link

in the figure above, the GPID carried in generalized label request is 
33(Ethernet), but in the label set below
    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                 
   | 

GPID=ODU3-ODU2-ODU1-ODU0

Wish this make it clear

B.R.

Fei

Khuzema Pithewan <[email-masked]> 
2011-03-17 13:42

收件人
"[email-masked]" <[email-masked]>, Rajan Rao 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

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: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Thursday, March 17, 2011 8:38 AM
To: Rajan Rao
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] I-D 
Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Dear Rajan 

5.1 Multi-stage Label 

    0                   1                   2                   3 

                 

Best regards 

Fei 

收件人

主题

Hi,

Thanks
Authors