Subject: Re: FW: [IP-Optical] GMPLS enhancements

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Feb 2001 11:23:20 +0100

Vishal,

Attached is a brief description of the features (increase/decrease of
VC-n-Xv group size and protection) that are introduced by the LCAS
extension of virtual concatenation.

Regards,

Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Feb 2001 13:34:03 +0100

Vishal,

Attached a short document further illustrating the need for two separate
SDH labels: one for HOVC/STS signals and the second one for LOVC/VT
signals.

Regards,

Maarten

---

From: Vishal Sharma <[email-masked]>
Date: Tue, 13 Feb 2001 21:36:52 -0800

I omitted to forward my initial response to all relevant WGs, so please
bear with the duplicates. I sent a duplicate on purpose, so subsequent 
discussion can proceed on all relevant lists (at least CCAMP and IPO).

Thanks,

-Vishal

-----Original Message-----
From: Vishal Sharma [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 9:26 PM
To: 'Maarten Vissers'; [email-masked]
Cc: Ben Mack-Crane (E-mail); Greg Bernstein (E-mail); Bala Rajagopalan
(E-mail); Debanjan Saha (E-mail); Michael Raftelis (E-mail); Shash
Chatterjee (E-mail); Jeff Connell (E-mail); Eric Mannie (E-mail)
Subject: RE: [IP-Optical] GMPLS enhancements

Maarten,

Thanks very much for your detailed comments and observations. Some of the 
discrepancies you mentioned were noted at the San Diego IETF (comments
from Jurgen), and we fixed some things thereafter. However, your comments on
some of
the new encodings for SDH in line with the newer specifications are
well-taken,
and we will need some time to review what you have sent and respond to it.

I have therefore forwarded your email to my co-authors (some of whom may not
be on the ip-optical list), and we will try to get back to you with a
response
in the next week or so. (Several people are traveling this week, so we may
not have a chance to discuss this before early next week.)

Regards,

-Vishal

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 7:45 AM
To: [email-masked]
Subject: [IP-Optical] GMPLS enhancements

Reading through draft-mack-crane-gmpls-signaling-enhancements-00.txt and
draft-ietf-mpls-generalized-signaling-01.txt, I came across a number of
items that do not align with SDH specifications and terminology. While
it is the intention to have GMPLS as the control plane of amongst others
SDH networks, it better matches the SDH specifications and terminology
in my opinion.

draft-ietf-mpls-generalized-signaling-01.txt
============================================

- In the G-PID table a number of entries are not supported by SDH
(G.707, 10/00):
 
            8     Bit synchronous mapping of E3          SDH
            9     Byte synchronous mapping of E3         SDH
           12     Byte synchronous mapping of DS2/T2     SDH

Items 19,20 and 21 are already defined under items 13,14 and 15.

           19     Same as 12 but in a VC-12              SDH
           20     Same as 13 but in a VC-12              SDH
           21     Same as 14 but in a VC-12              SDH

draft-mack-crane-gmpls-signaling-enhancements-00.txt
====================================================

- In the G-PID table for SDH, the following items are not supported by
SDH (G.707, 10/00):

                   5         Byte synchronous mapping of E3
                   8         Byte synchronous mapping of DS2

draft-mack-crane-gmpls-signaling-enhancements-00.txt
====================================================

- In the LSP Encoding table for ETSI-PDH, the E3 and E4 signals are
defined as a single entity, suggesting a single frame format to be
present. For E3 and E4 however, multiple frame formats are defined; the
traditional PDH ones define in G.751 and the newer ones that can carry
ATM and SDH signals (defined in G.832 and ETS 300 337). The former frame
formats are identified as P31e and P4e signals, whereas the latter ones
are identified as P31s and P4s signals; refer to EN 300 417-5-1 and EN
300 417-4-1.

For the case the frame format is unimportant, the signals are identified
as P31x, P4x (x refers to transparent transport of the bit stream).

To be complete, the ETSI-PDH LSP encoding should be extended as follows:

   Permitted values and their meaning for LSP Encoding Type ETSI-PDH:

                 Value       Type
                 -----       ----
                   1         E1 P12x
                   2         E1 P12s
                   3         E2 P22x
                   4         E2 P22e
                   5         E3 P31x
                   6         E3 P31e
                   7         E2 P31s
                   8         E4 P4x
                   9         E4 P4e
                   10        E4 P4s

For mapping of these ETSI-PDH signals into SDH, these distinctions might
also be important; e.g. a E4 signal might be processed as a transparent
bit stream in the SDH equipment, or it might be terminated and its E3
tributary signals demultiplexed, or it might be terminated and its ATM
payload being extracted. Refer to EN 300 417-4-1 for the set of
alternatives as reflected in the set of adaptation functions.

   When the technology encoding type is SDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                   0         Unknown
                   1         Asynchronous mapping of E4 P4x
                   x         Asynchronous mapping of E4 P4e
                   x         Asynchronous mapping of E4 P4s
                   2         Asynchronous mapping of DS3
                   3         Asynchronous mapping of E3 P3x
                   x         Asynchronous mapping of E3 P3e
                   x         Asynchronous mapping of E3 P3s
                   5         Byte synchronous mapping of E3
                   6         Asynchronous mapping of DS2
                   7         Bit synchronous mapping of DS2
                   8         Byte synchronous mapping of DS2
                   9         Asynchronous mapping of E1 P12x
                   x         Asynchronous mapping of E1 P12s
                  10         Byte synchronous mapping of E1 P12s
                  11         Byte synchronous mapping of 31 * DS0
                  12         Asynchronous mapping of DS1
                  13         Bit synchronous mapping of DS1
                  14         Byte synchronous mapping of DS1
                  15         ATM mapping

draft-ietf-mpls-generalized-signaling-01.txt and
draft-mack-crane-gmpls-signaling-enhancements-00.txt
====================================================

The Requested Grouping Type (RGT) defines virtual concatenation as a
co-routed group. This is not supporting a major new feature in this
virtual concatenation application: Link Capacity Adjustment Scheme
(LCAS). 

LCAS is recently defined in T1X1.5 and ITU-T SG15, and is based on the
fact that the signals in the virtual concatenated group are transported
via multiple server layer signals (diverse routing). Refer to
ftp://ftp.t1.org/T1X1/X1.0/1x100060.doc
ftp://ftp.t1.org/T1X1/X1.0/1x100060.pdf

The control plane for SDH/SONET should not introduce a restriction on
the SDH/SONET networking functionality. As such, co-routing should not
longer be associated with virtual concatenation.

draft-ietf-mpls-generalized-signaling-01.txt
============================================

In section "3.2.1.1. SDH and SONET Labels", "S" is defined as: 
      "S is the index of a particular STM-1/STS-1 signal. S=1->N
      indicates a specific STM-1/STS-1 inside an STM-N/STS-N
      multiplex. For example, S=1 indicates the first STM-1/STS-1,
      and S=N indicates the last STM-1/STS-1 of this multiplex.  S=0
      is invalid.".

This specification is not aligned with SDH terminology. A STM-1 isn't a
timeslot of an STM-N!!!! AU is the name of a (higher order) timeslot of
a STM-N, and AUG is the name for a group of AUs. The text should
therefore read as follows:
      "S is the index of a particular AUG-1/STS-1 signal. S=1->N
      indicates a specific AUG-1/STS-1 inside an STM-N/STS-N
      multiplex. For example, S=1 indicates the first AUG-1/STS-1,
      and S=N indicates the last AUG-1/STS-1 of this multiplex.  S=0
      is invalid."

And consequently, definition of "U" must be enhanced as follows:
      "U is only significant for SDH and must be ignored for SONET. It
      indicates a specific VC inside a given AUG-1. U=1 indicates a
      single VC-4, while U=2->4 indicates a specific VC-3 inside the
      given AUG-1."

Note that the latest version of G.707 (10/00) has defined a naming
structure for the AU's, similar to that for the TU's. AUs are now named
according the EDCBA structure (TUs are named according the KLM
structure). It is thus possible to replace the S,U number by the
standardised number E,D,C,B,A. The specification could be:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         |  E  |  D  |  C  |  B  |  A  |   K   |   L   |   M   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For SDH, this is an extension of the numbering scheme defined in
   G.707 section 7.3, i.e. the (E,D,C,B,A) and (K, L, M) numbering. For 
   SONET the K field is not significant and must be set to zero.

   Each letter indicates a possible branch number starting at the parent
   node in the multiplex structure. Branches are considered as numbered
   in increasing order, starting from the top of the multiplexing
   structure. The numbering starts at 1, zero is used to indicate a non-
   significant field.

   When a field is not significant in a particular context it MUST be
   set to zero when transmitted, and MUST be ignored when received.

   1. E indicates possible branches of a STM-256/OC786. It is not 
      meaningful for the cases of STM-64/OC192, STM-16/OC48, STM-4/OC12,
      STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case.
      E=1 indicates that the STM-256/OC768 is not further sub-divided
      and contains an AU-4-256c/STS768c. 
      E=2->5 indicates a specific AUG-64 inside the given STM-256/OC768.

   2. D indicates possible branches of either an AUG-64 or a
STM-64/OC192. 
      It is not meaningful for the cases of STM-16/OC48, STM-4/OC12,
      STM-1/OC-3, STM-0/OC1 multiplexing and must be 0 in that case. 
      D=1 indicates that the AUG-64 or STM-64/OC192 is not further
      sub-divided and contains an AU-4-64c/STS192c.
      D=2->5 indicates a specific AUG-16 inside the given AUG-64 or 
      STM-64/OC192.

   3. C indicates possible branches of either an AUG-16 or a
STM-16/OC48.
      It is not meaningful for the cases of STM-4/OC12, STM-1/OC3,
      STM-0/OC1 multiplexing and must be 0 in that case. 
      C=1 indicates that the AUG-16 or STM-16/OC48 is not further
      sub-divided and contains an AU-4-16c/STS48c. 
      C=2->5 indicates a specific AUG-4 inside the given AUG-16 or 
      STM-16/OC48.

   4. B indicates possible branches of either an AUG-4 or a STM-4/OC12.
      It is not meaningful for the cases of STM-1/OC3, STM-0/OC1
      multiplexing and must be 0 in that case. 
      B=1 indicates that the AUG-4 or STM-4/OC12 is not further 
      sub-divided and contains an AU-4-4c/STS12c.
      B=2->5 indicates a specific AUG-1 inside the given AUG-4 or 
      STM-4/OC12.

   5. A indicates possible branches of either an AUG-1 or a STM-1/OC3.
      It is not meaningful for the case of STM-0/OC1 multiplexing 
      and must be 0 in that case. A=1 indicates that the AUG-1 or
      STM-1/OC3 is not further sub-divided and contains an 
      AU-4/STS3c. A=2->4 indicates a specific AU-3/STS1 inside the given
      AUG-1 or STM-1/OC3.

   6. K is only significant for SDH and must be ignored for SONET. It
      indicates a specific branch of a VC-4. K=1 indicates that the
      VC-4 is not further sub-divided and contains a C-4. K=2->4
      indicates a specific TUG-3 inside the VC-4. K is not
      significant when the STM-1 is divided into VC-3s (easy to read
      and test).

   7. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It
      is not significant for an unstructured VC-4. L=1 indicates that
      the TUG-3/VC-3/STS-1 SPE is not further sub-divided and
      contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8
      indicates a specific TUG-2/VT Group inside the corresponding
      higher order signal.

   8. M indicates a specific branch of a TUG-2/VT Group. It is not
      significant for an unstructured VC-4, TUG-3, VC-3 or STS-1
      SPE. M=1 indicates that the TUG-2/VT Group is not further
      sub-divided and contains a VC-2/VT-6. M=2->3 indicates a
      specific VT-3 inside the corresponding VT Group, these values
      MUST NOT be used for SDH since there is no equivalent of VT-3
      with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the
      corresponding TUG-2/VT Group. M=7->10 indicates a specific
      VC-11/VT-1.5 inside the corresponding TUG-2/VT Group carried
      within a TU-11. M=11->13 indicates a specific VC-11 inside the
      corresponding TUG-2 carried within a TU-12. Note that M=0 denotes
      an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging).

Some examples:
  EDCBAKLM
- 00220444 identifies TU12 (1,1,1) in a VC4 carried in AU4 (1,1,0)
	   in a STM-16/OC48
- 10000000 identifies AU-4-256c/STS768c in a STM-256/OC768
- 23450455 identifies TU12 (3,4,2) in a VC-4 carried in AU-4 (1,2,3,4,0)
	   in a STM-256/OC768
- 03210000 identifies AU-4-4c (2,1,0,0) in a STM-64/OC192
- 00241000 identifies AU-4 (1,3,0) in a STM-16/OC48 signal.

The specification of the AU timeslot (2x AU-4-4c, 7xAU-4, 3xAU-3)
structure in a STM-16 could then consist of the following set of labels:

  EDCBAKLM
- 00210000 AU-4-4c (1,0,0)
- 00321000 AU-4 (2,1,0)
- 00331000 AU-4 (2,2,0)
- 00341000 AU-4 (2,3,0)
- 00351000 AU-4 (2,4,0)
- 00410000 AU-4-4c (3,0,0)
- 00521000 AU-4 (4,1,0)
- 00532000 AU-3 (4,2,1)
- 00533000 AU-3 (4,2,2)
- 00534000 AU-3 (4,2,3)
- 00541000 AU-4 (4,3,0)
- 00551000 AU-4 (4,4,0)

For the contiguous concatenated signals (AU-4-Xc) the EDCBA numbering
scheme has the bandwidth implied. There is no need to code this
bandwidth seperately anylonger.

Question related to the definition of "M": 
------------------------------------------
"M" defines 1st - 3rd VC-12 and 1st - 4th VC-11. As it is possible to
transport a VC-11 via a TU-12, I believe that the M range should be
extended with values 11 to 13 as follows:

   The M encoding is summarized in the following table:

       M           SDH                             SONET
      ----------------------------------------------------------
       0           unstructured VC-4/VC-3  unstructured STS-1 SPE
       1           VC-2                            VT-6
       2           -                               1st VT-3
       3           -                               2nd VT-3
       4           1st VC-12                       1st VT-2
       5           2nd VC-12                       2nd VT-2
       6           3rd VC-12                       3rd VT-2
       7           1st VC-11 in TU-11              1st VT-1.5
       8           2nd VC-11 in TU-11              2nd VT-1.5
       9           3rd VC-11 in TU-11              3rd VT-1.5
       10          4th VC-11 in TU-11              4th VT-1.5
       11          1st VC-11 in TU-12              -
       12          2nd VC-11 in TU-12              -
       13          3rd VC-11 in TU-12              -

At intermediate points, the VC-11 in TU-12 is treated (by non-intrusive
monitors) as a VC-12. At the path endpoints however, the VC-11 is
treated as a VC-11.

Coding the lower order VC (LOVC)/VT signals:
--------------------------------------------
SDH ADM and cross connect equipment may have separate Higher Order and
Lower Order fabrics. This decouples the TU identification from the AU
timeslot and associated physical port. I.e. EDCBAKLM label should be
split into separate EDCBA and KLM labels.

Figure 1 illustrates an SDH ADM with 3 STM-N ports, a HO Fabric and "M"
VC4 termination points connected to the LO Fabric. 

The TU timeslots are defined with reference to a VC4 termination point.
The VC4 signal geenrated by a VC4 termination point can be transported
over any of the STM-N signals; there is no predefined relationship,
neither is there a permanent relationship (i.e. it is possible to
re-route the VC-4 without tearing it down, or tearing down the LOVC
connection over it).

As such, the TU timeslots should be numbered with respect to its VC4
termination point, not with respect to the AU4 timeslot in an STM-N; The
AU4/STM-N part of the label may change over time, whereas the TU link
connection and TU connection point stay the same.
Resulting label should be "<VC4 TP number><K><L><M>".

STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
FABRIC
signal	  PORT    timeslots     |  |        Term.      timeslots
                                |  |        Points     per VC4 TP
                                |  |
STM-N --- PHY --- "N" AU -------|  |
                  timeslots        |
STM-N --- PHY --- "N" AU ----------|
                  timeslots

		Figure 1 - SDH ADM with separate HO and LO Fabrics

The HO Fabric contains the relation between AU number and VC4 TP number,
as well as between between two AU numbers (case of STM-N - AU - STM-N
connection).

      <-- phys. <--- EDCBA               <--- VC4       <--- KLM
          port       AU                       TP             TU
          number     number                   number         number

STM-N --- PHY --- "N" AU --- HO Fabric --- "M" VC4 --- "Z" TU --- LO
FABRIC
signal	  PORT    timeslots     |  |        Term.      timeslots
                                |  |        Points     per VC4 TP

			Figure 2 - numbering

Regards,

Maarten

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical