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

[[e-mail]]

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

GPID=ODU3-ODU2-ODU1-ODU0

Wish this make it clear

B.R.

Fei



Khuzema Pithewan <[e-mail]> 
2011-03-17 13:42

收件人
"[e-mail]" <[e-mail]>, Rajan Rao 
<[e-mail]>
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
主题
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: [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