The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] FW: [IP-Optical] GMPLS enhancements
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:vishal@JasmineNetworks.com]
Sent: Tuesday, February 13, 2001 9:26 PM
To: 'Maarten Vissers'; ip-optical@lists.bell-labs.com
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:mvissers@lucent.com]
Sent: Tuesday, February 13, 2001 7:45 AM
To: ip-optical@lists.bell-labs.com
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
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical
|
|