draft-ietf-ccamp-gmpls-sonet-sdh-02.txt   draft-ietf-ccamp-gmpls-sonet-sdh-03.txt 
CCAMP Working Group Eric Mannie (Ebone) - Editor CCAMP Working Group Eric Mannie (Ebone) - Editor
Internet Draft Internet Draft
Expiration Date: April 2001 Stefan Ansorge (Alcatel) Expiration Date: June 2002 Stefan Ansorge (Alcatel)
Peter Ashwood-Smith (Nortel) Peter Ashwood-Smith (Nortel)
Ayan Banerjee (Calient) Ayan Banerjee (Calient)
Lou Berger (Movaz) Lou Berger (Movaz)
Greg Bernstein (Ciena) Greg Bernstein (Ciena)
Angela Chiu (Celion) Angela Chiu (Celion)
John Drake (Calient) John Drake (Calient)
Yanhe Fan (Axiowave) Yanhe Fan (Axiowave)
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Juergen Heiles(Siemens) Juergen Heiles(Siemens)
skipping to change at line 34 skipping to change at line 34
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper) Yakov Rekhter (Juniper)
Debanjan Saha (Tellium) Debanjan Saha (Tellium)
Vishal Sharma (Metanoia) Vishal Sharma (Metanoia)
George Swallow (Cisco) George Swallow (Cisco)
Z. Bo Tang (Tellium) Z. Bo Tang (Tellium)
Eve Varma (Lucent) Eve Varma (Lucent)
Maarten Vissers (Lucent) Maarten Vissers (Lucent)
Yangguang Xu (Lucent) Yangguang Xu (Lucent)
October 2001 December 2001
GMPLS Extensions for SONET and SDH Control GMPLS Extensions for SONET and SDH Control
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
E. Mannie Editor 1 E. Mannie Editor 1
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a companion to the Generalized MPLS signaling This document is a companion to the Generalized MPLS signaling
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines
the SONET/SDH technology specific information needed when using the SONET/SDH technology specific information needed when using
GMPLS signaling. GMPLS signaling.
1. Introduction 1. Introduction
Generalized MPLS (GMPLS) extends MPLS from supporting packet Generalized MPLS (GMPLS) extends MPLS from supporting packet
(Packet Switching Capable - PSC) interfaces and switching to (Packet Switching Capable - PSC) interfaces and switching to
include support of three new classes of interfaces and switching: include support of four new classes of interfaces and switching:
Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber- Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM),
Switch (FSC). A functional description of the extensions to MPLS Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A
signaling needed to support the new classes of interfaces and functional description of the extensions to MPLS signaling needed
switching is provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP- to support the new classes of interfaces and switching is provided
TE specific formats and mechanisms needed to support all four in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats
classes of interfaces, and CR-LDP extensions can be found in and mechanisms needed to support all five classes of interfaces,
[GMPLS-LDP]. This document presents details that are specific to and CR-LDP extensions can be found in [GMPLS-LDP]. This document
SONET/SDH. Per [GMPLS-SIG], SONET/SDH specific parameters are presents details that are specific to SONET/SDH. Per [GMPLS-SIG],
carried in the signaling protocol in traffic parameter specific SONET/SDH specific parameters are carried in the signaling
objects. protocol in traffic parameter specific objects.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
2. SDH and SONET Traffic Parameters 2. SDH and SONET Traffic Parameters
This section defines the GMPLS traffic parameters for SONET/SDH. This section defines the GMPLS traffic parameters for SONET/SDH.
The protocol specific formats, for the SDH/SONET-specific RSVP-TE The protocol specific formats, for the SDH/SONET-specific RSVP-TE
objects and CR-LDP TLVs are described in sections 2.2 and 2.3 objects and CR-LDP TLVs are described in sections 2.2 and 2.3
skipping to change at line 107 skipping to change at line 107
concatenation and transparency. Some extra non-standard concatenation and transparency. Some extra non-standard
capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents capabilities are defined in [GMPLS-SONET-SDH-EXT]. Other documents
could further enhance this set of capabilities in the future. For could further enhance this set of capabilities in the future. For
instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0 instance, signaling for SDH over PDH (ITU-T G.832), or sub-STM-0
(ITU-T G.708) interfaces could be defined. (ITU-T G.708) interfaces could be defined.
The traffic parameters defined hereafter MUST be used when The traffic parameters defined hereafter MUST be used when
SONET/SDH is specified in the LSP Encoding Type field of a SONET/SDH is specified in the LSP Encoding Type field of a
Generalized Label Request [GMPLS-SIG]. Generalized Label Request [GMPLS-SIG].
E. Mannie Editor Internet-Draft April 2001 2 E. Mannie Editor Internet-Draft June 2002 2
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
A SONET signal which has an identical SDH signal SHOULD be
requested using the same traffic parameters as for the equivalent
SDH signal, and will consequently use the SDH label.
2.1. SONET/SDH Traffic Parameters 2.1. SONET/SDH Traffic Parameters
The traffic parameters for SONET/SDH is organized as follows: The traffic parameters for SONET/SDH is organized as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RCC | NCC | | Signal Type | RCC | NCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 143 skipping to change at line 147
Each transform is optional and must be ignored if zero, except Each transform is optional and must be ignored if zero, except
MT that cannot be zero and is ignored if equal to one. MT that cannot be zero and is ignored if equal to one.
Transforms must be applied strictly in the following order: Transforms must be applied strictly in the following order:
- First, contiguous concatenation (by using the RCC and NCC - First, contiguous concatenation (by using the RCC and NCC
fields) can be optionally applied on the Elementary Signal, fields) can be optionally applied on the Elementary Signal,
resulting in a contiguously concatenated signal. resulting in a contiguously concatenated signal.
- Second, virtual concatenation (by using the NVC field) can - Second, virtual concatenation (by using the NVC field) can
be optionally applied either directly on the Elementary be optionally applied either directly on the Elementary
Signal, or optionally on the contiguously concatenated Signal, or on the contiguously concatenated signal obtained
signal obtained from the previous phase (see [GMPLS-SONET- from the previous phase (see [GMPLS-SONET-SDH-EXT]).
SDH-EXT]).
- Third, some transparency can be optionally specified when - Third, some transparency can be optionally specified when
requesting a frame as signal rather than an SPE or VC based requesting a frame as signal rather than an SPE or VC based
signal (by using the Transparency field). signal (by using the Transparency field).
- Fourth, a multiplication (by using the Multiplier field) can be - Fourth, a multiplication (by using the Multiplier field) can be
optionally applied either directly on the Elementary Signal, or optionally applied either directly on the Elementary Signal, or
on the contiguously concatenated signal obtained from the first on the contiguously concatenated signal obtained from the first
phase, or on the virtually concatenated signal obtained from phase, or on the virtually concatenated signal obtained from
the second phase, or on these signals combined with some the second phase, or on these signals combined with some
transparency. transparency.
E. Mannie Editor Internet-Draft April 2001 3 E. Mannie Editor Internet-Draft June 2002 3
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Permitted Signal Type values for SONET/SDH are: Permitted Signal Type values for SONET/SDH are:
Value Type Value Type
----- ----------------- ----- -----------------
1 VT1.5 SPE / VC-11 1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12 2 VT2 SPE / VC-12
3 VT3 SPE 3 VT3 SPE
4 VT6 SPE / VC-2 4 VT6 SPE / VC-2
5 STS-1 SPE / VC-3 5 STS-1 SPE / VC-3
skipping to change at line 181 skipping to change at line 184
9 STS-12 / STM-4 (only when requesting transparency) 9 STS-12 / STM-4 (only when requesting transparency)
10 STS-48 / STM-16 (only when requesting transparency) 10 STS-48 / STM-16 (only when requesting transparency)
11 STS-192 / STM-64 (only when requesting transparency) 11 STS-192 / STM-64 (only when requesting transparency)
12 STS-768 / STM-256 (only when requesting transparency) 12 STS-768 / STM-256 (only when requesting transparency)
A dedicated signal type is assigned to a SONET STS-3c SPE instead A dedicated signal type is assigned to a SONET STS-3c SPE instead
of coding it as a contiguous concatenation of three STS-1 SPEs. of coding it as a contiguous concatenation of three STS-1 SPEs.
This is done in order to provide easy interworking between SONET This is done in order to provide easy interworking between SONET
and SDH signaling. and SDH signaling.
Refer to Appendix 1 and Appendix 2 for an extended set of signal Appendix 1 adds one more signal type (optional). Refer to [GMPLS-
type values beyond the signal types as defined in T1.105/G.707. SDH-SONET-EXT] for an extended set of signal type values beyond
the signal types as defined in T1.105/G.707.
Requested Contiguous Concatenation (RCC): 8 bits Requested Contiguous Concatenation (RCC): 8 bits
This field is used to request and sometimes negotiate (see This field is used to request and sometimes negotiate (see
[GMPLS-SDH-SONET-EXT]) the optional SONET/SDH contiguous [GMPLS-SDH-SONET-EXT]) the optional SONET/SDH contiguous
concatenation of the Elementary Signal. concatenation of the Elementary Signal.
This field is a vector of flags. Each flag indicates the This field is a vector of flags. Each flag indicates the
support of a particular type of contiguous concatenation. support of a particular type of contiguous concatenation.
Several flags can be set at the same time to indicate a choice. Several flags can be set at the same time to indicate a choice.
These flags allow an upstream node to indicate to a downstream These flags allow an upstream node to indicate to a downstream
node the different types of contiguous concatenation that it node the different types of contiguous concatenation that it
supports. However, the downstream node decides which one to use supports. However, the downstream node decides which one to use
according to its own rules. according to its own rules.
A downstream node receiving simultaneously more than one flag A downstream node receiving simultaneously more than one flag
chooses, as it likes, a particular type of contiguous chooses a particular type of contiguous concatenation, if any
concatenation, if any supported. A downstream node that doesnĘt supported, and based on criteria that are out of this document
support any of the concatenation types indicated by the field scope. A downstream node that doesnĘt support any of the
must refuse the LSP request. In particular, it must refuse the concatenation types indicated by the field must refuse the LSP
LSP request if it doesnĘt support contiguous concatenation at request. In particular, it must refuse the LSP request if it
all. doesnĘt support contiguous concatenation at all.
The upstream node know which type of contiguous concatenation The upstream node knows which type of contiguous concatenation
the downstream node chosen by looking at the position indicated the downstream node chosen by looking at the position indicated
by the first label and the number of label(s) as returned by by the first label and the number of label(s) as returned by
the downstream node. the downstream node.
E. Mannie Editor Internet-Draft April 2001 4 E. Mannie Editor Internet-Draft June 2002 4
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
The entire field is set to zero to indicate that no contiguous The entire field is set to zero to indicate that no contiguous
concatenation is requested at all (default value). A non-zero concatenation is requested at all (default value). A non-zero
field indicates that some contiguous concatenation is being field indicates that some contiguous concatenation is
requested. requested.
The following flag is defined: The following flag is defined:
Flag 1 (bit 1): Standard contiguous concatenation. Flag 1 (bit 1): Standard contiguous concatenation.
Flag 1 indicates that only the standard SONET/SDH contiguous Flag 1 indicates that only the standard SONET/SDH contiguous
concatenation as defined in T1.105/G.707 is supported. Note concatenation as defined in T1.105/G.707 is supported. Note
that bit 1 is the low order bit. Other flags are reserved for that bit 1 is the low order bit. Other flags are reserved for
extensions, if not used they should be set to zero when sent, extensions, if not used they must be set to zero when sent, and
and should be ignored when received. should be ignored when received.
See note 1 hereafter in the section on the NCC about the SONET See note 1 hereafter in the section on the NCC about the SONET
contiguous concatenation of STS-1 SPEs when the number of contiguous concatenation of STS-1 SPEs when the number of
components is a multiple of three. components is a multiple of three.
Refer to [GMPLS-SONET-SDH-EXT] for an extended set of contiguous Refer to [GMPLS-SONET-SDH-EXT] for an extended set of contiguous
concatenation types beyond the contiguous concatenation types as concatenation types beyond the contiguous concatenation types as
defined in T1.105/G.707. defined in T1.105/G.707.
Number of Contiguous Components (NCC): 16 bits Number of Contiguous Components (NCC): 16 bits
skipping to change at line 265 skipping to change at line 269
SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and SPE, the signal type must be STM-N/STS-N, RCC with flag 1 and
NCC set to 1. NCC set to 1.
This field is irrelevant if no contiguous concatenation is This field is irrelevant if no contiguous concatenation is
requested (RCC = 0), in that case it must be set to zero when requested (RCC = 0), in that case it must be set to zero when
send, and should be ignored when received. A RCC value send, and should be ignored when received. A RCC value
different from 0 must imply a number of components greater than different from 0 must imply a number of components greater than
1. The NCC value must be consistent with the type of contiguous 1. The NCC value must be consistent with the type of contiguous
concatenation being requested in the RCC field. concatenation being requested in the RCC field.
E. Mannie Editor Internet-Draft April 2001 5 E. Mannie Editor Internet-Draft June 2002 5
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Number of Virtual Components (NVC): 16 bits Number of Virtual Components (NVC): 16 bits
This field indicates the number of signals that are requested This field indicates the number of signals that are requested
to be virtually concatenated. These signals are all of the same to be virtually concatenated. These signals are all of the same
type by definition. They are Elementary Signal SPEs/VCs for type by definition. They are Elementary Signal SPEs/VCs for
which signal types are defined in this document, i.e. VT1.5 which signal types are defined in this document, i.e. VT1.5
SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11, SPE, VT2 SPE, VT3 SPE, VT6 SPE, STS-1 SPE, STS-3c SPE, VC-11,
VC-12, VC-2, VC-3 or VC-4. VC-12, VC-2, VC-3 or VC-4.
skipping to change at line 314 skipping to change at line 318
invalid value. invalid value.
Transparency (T): 32 bits Transparency (T): 32 bits
This field is a vector of flags that indicates the type of This field is a vector of flags that indicates the type of
transparency being requested. Several flags can be combined to transparency being requested. Several flags can be combined to
provide different types of transparency. Not all combinations provide different types of transparency. Not all combinations
are necessarily valid. The default value for this field is are necessarily valid. The default value for this field is
zero, i.e. no transparency requested. zero, i.e. no transparency requested.
Transparency as defined from the point of view of this Transparency, as defined from the point of view of this
signaling specification is only applicable to the fields in the signaling specification, is only applicable to the fields in
SONET/SDH frame overheads. In the SONET case, these are the the SONET/SDH frame overheads. In the SONET case, these are the
fields in the Section Overhead (SOH), and the Line Overhead fields in the Section Overhead (SOH), and the Line Overhead
(LOH). In the SDH case, these are the fields in the Regenerator (LOH). In the SDH case, these are the fields in the Regenerator
Section Overhead (RSOH), the Multiplex Section overhead (MSOH), Section Overhead (RSOH), the Multiplex Section overhead (MSOH),
and the pointer fields between the two. With SONET, the pointer and the pointer fields between the two. With SONET, the pointer
fields are part of the LOH. fields are part of the LOH.
E. Mannie Editor Internet-Draft April 2001 6 E. Mannie Editor Internet-Draft June 2002 6
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Note as well that transparency is only applicable when using Note as well that transparency is only applicable when using
the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM- the following Signal Types: STM-0, STM-1, STM-4, STM-16, STM-
64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS- 64, STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-
768. At least one transparency type must be specified when 768. At least one transparency type must be specified when
requesting such a signal type. requesting such a signal type.
Transparency indicates precisely which fields in these Transparency indicates precisely which fields in these
overheads must be delivered unmodified at the other end of the overheads must be delivered unmodified at the other end of the
LSP. An ingress LSR requesting transparency will pass these LSP. An ingress LSR requesting transparency will pass these
skipping to change at line 378 skipping to change at line 382
types beyond the transparency types as defined in T1.105/G.707. types beyond the transparency types as defined in T1.105/G.707.
2.2. RSVP-TE Details 2.2. RSVP-TE Details
For RSVP-TE, the SONET/SDH traffic parameters are carried in the For RSVP-TE, the SONET/SDH traffic parameters are carried in the
SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is
used both for SENDER_TSPEC object and FLOWSPEC objects. The used both for SENDER_TSPEC object and FLOWSPEC objects. The
contents of the objects is defined above in Section 2.1. The contents of the objects is defined above in Section 2.1. The
objects have the following class and type: objects have the following class and type:
E. Mannie Editor Internet-Draft April 2001 7 E. Mannie Editor Internet-Draft June 2002 7
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
For SONET ANSI T1.105 and SDH ITU-T G.707: For SONET ANSI T1.105 and SDH ITU-T G.707:
SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (TBA) SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (TBA)
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (TBA) SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (TBA)
There is no Adspec associated with the SONET/SDH SENDER_TSPEC. There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an int-serv Adspec with the Either the Adspec is omitted or an int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210]. fragment is used, see [RFC2210].
skipping to change at line 420 skipping to change at line 424
The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA. The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA.
3. SDH and SONET Labels 3. SDH and SONET Labels
SDH and SONET each define a multiplexing structure, with the SONET SDH and SONET each define a multiplexing structure, with the SONET
multiplex structure being a subset of the SDH multiplex structure. multiplex structure being a subset of the SDH multiplex structure.
These two structures are trees whose roots are respectively an These two structures are trees whose roots are respectively an
STM-N or an STS-N; and whose leaves are the signals that can be STM-N or an STS-N; and whose leaves are the signals that can be
transported via the time-slots and switched between time-slots, transported via the time-slots and switched between time-slots,
i.e. a VC-x or a VT-x. An SDH/SONET label will identify the exact i.e. a VC-x, a VT-x SPE or an STS SPE. An SDH/SONET label will
position of a particular signal in a multiplexing structure. SDH identify the exact position of a particular signal in a
and SONET labels are carried in the Generalized Label per [GMPLS- multiplexing structure. SDH and SONET labels are carried in the
RSVP] and [GMPLS-LDP]. Generalized Label per [GMPLS-RSVP] and [GMPLS-LDP].
These multiplexing structures will be used as naming trees to These multiplexing structures will be used as naming trees to
create unique multiplex entry names or labels. Since the SONET create unique multiplex entry names or labels. Since the SONET
multiplexing structure may be seen as a subset of the SDH multiplexing structure may be seen as a subset of the SDH
multiplexing structure, the same format of label is used for SDH multiplexing structure, the same format of label is used for SDH
and SONET. As explained in [GMPLS-SIG], a label does not identify and SONET. As explained in [GMPLS-SIG], a label does not identify
the "class" to which the label belongs. This is implicitly the "class" to which the label belongs. This is implicitly
determined by the link on which the label is used. However, in determined by the link on which the label is used.
E. Mannie Editor Internet-Draft April 2001 8
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
some cases the encoding specified hereafter can make the direct E. Mannie Editor Internet-Draft June 2002 8
distinction between SDH and SONET. draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
In case of signal concatenation or multiplication, a list of In case of signal concatenation or multiplication, a list of
labels can appear in the Label field of a Generalized Label. labels can appear in the Label field of a Generalized Label.
In case of contiguous concatenation, only one label appears in the In case of contiguous concatenation, only one label appears in the
Label field. That label is the lowest signal of the contiguously Label field. This label is the lowest signal of the contiguously
concatenated signal. By lowest signal we mean the one having the concatenated signal. By lowest signal we mean the one having the
lowest label when compared as integer values, i.e. the first lowest label when compared as integer values, i.e. the first
component signal of the concatenated signal encountered when component signal of the concatenated signal encountered when
descending the tree. descending the tree.
In case of virtual concatenation, the explicit ordered list of all In case of virtual concatenation, the explicit ordered list of all
labels in the concatenation is given. Each label indicates a labels in the concatenation is given. Each label indicates a
component of the virtually concatenated signal. The order of the component of the virtually concatenated signal. The order of the
labels must reflect the order of the payloads to concatenate (not labels must reflect the order of the payloads to concatenate (not
the physical order of time-slots). The above representation limits the physical order of time-slots). The above representation limits
virtual concatenation to remain within a single (component) link; virtual concatenation to remain within a single (component) link;
it imposes as such a restriction compared to the specification in it imposes as such a restriction compared to the G.707/T1.105
G.707/T1.105. recommendations.
In case of multiplication (i.e. using the multiplier transform), In case of multiplication (i.e. using the multiplier transform),
the explicit ordered list of all labels that take part in the the explicit ordered list of all labels that take part in the
Final Signal is given. In case of multiplication of virtually Final Signal is given. In case of multiplication of virtually
concatenated signals, the first set of labels indicates the first concatenated signals, the first set of labels indicates the first
virtually concatenated signal, the second set of labels indicates virtually concatenated signal, the second set of labels indicates
the second virtually concatenated signal, and so on. The above the second virtually concatenated signal, and so on. The above
representation limits multiplication to remain within a single representation limits multiplication to remain within a single
(component) link. (component) link.
skipping to change at line 479 skipping to change at line 480
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S | U | K | L | M | | S | U | K | L | M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For SDH, this is an extension of the numbering scheme defined in For SDH, this is an extension of the numbering scheme defined in
G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U
and K fields are not significant and must be set to zero. Only the and K fields are not significant and must be set to zero. Only the
S, L and M fields are significant for SONET and have a similar S, L and M fields are significant for SONET and have a similar
meaning as for SDH. semantic as for SDH.
Each letter indicates a possible branch number starting at the Each letter indicates a possible branch number starting at the
parent node in the multiplex structure. Branches are considered as parent node in the multiplex structure. Branches are considered as
numbered in increasing order, starting from the top of the numbered in increasing order, starting from the top of the
multiplexing structure. The numbering starts at 1, zero is used to multiplexing structure. The numbering starts at 1, zero is used to
indicate a non-significant field. indicate a non-significant or ignored 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.
E. Mannie Editor Internet-Draft April 2001 9 When a field is not significant or ignored in a particular context
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 it MUST be set to zero when transmitted, and MUST be ignored when
received.
When hierarchical SDH/SONET LSPs are used, an LSP with a given When hierarchical SDH/SONET LSPs are used, an LSP with a given
bandwidth can be used to tunnel lower order LSPs. The higher bandwidth can be used to tunnel lower order LSPs. The higher
E. Mannie Editor Internet-Draft June 2002 9
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
order SDH/SONET LSP behaves as a virtual link with a given order SDH/SONET LSP behaves as a virtual link with a given
bandwidth (e.g. VC-3), it may also be used as a Forwarding bandwidth (e.g. VC-3), it may also be used as a Forwarding
Adjacency. A lower order SDH/SONET LSP can be established through Adjacency. A lower order SDH/SONET LSP can be established through
that higher order LSP. Since a label is local to a (virtual) link, that higher order LSP. Since a label is local to a (virtual) link,
the highest part of that label is non-significant and is set to the highest part of that label is non-significant and is set to
zero. zero.
For instance, a VC-3 LSP can be advertised as a forwarding For instance, a VC-3 LSP can be advertised as a forwarding
adjacency. In that case the labels allocated between the two ends adjacency. In that case the labels allocated between the two ends
of that LSP (i.e. for that "link") will have S, U and K set to of that LSP (i.e. for that "link") will have S, U and K set to
zero, i.e., non-significant, while L and M will be used to zero, i.e., non-significant, while L and M will be used to
indicate the signal allocated in that VC-3. indicate the signal allocated in that VC-3.
1. S is the index of a particular AUG-1/STS-1. S=1->N indicates The possible values of S, U, K, L and M are defined as it follows:
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.
2. U is only significant for SDH and must be ignored for SONET. 1. S is only significant for SDH STM-N (N>0) and SONET. It must
It indicates a specific VC inside a given AUG-1. U=1 indicates a be ignored for STM-0. S is the index of a particular AUG-1/STS-
single VC-4, while U=2->4 indicates a specific VC-3 inside the 1. S=1->N indicates a specific AUG-1/STS-1 inside an STM-N/STS-N
given AUG-1. 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.
3. K is only significant for SDH VC-4 and must be ignored for 2. U is only significant for SDH STM-N (N>0) and must be ignored
SONET and SDH HOVC-3. It indicates a specific branch of a VC-4. for STM-0 and SONET. It indicates a specific VC inside a given
K=1 indicates that the VC-4 is not further subdivided and AUG-1. U=1 indicates a single VC-4, while U=2->4 indicates a
contains a C-4. K=2->4 indicates a specific TUG-3 inside the VC- specific VC-3 inside the given AUG-1.
4. K is not significant when the AUG-1 is divided into AU-3s
(easy to read and test). 3. K is only significant for SDH VC-4 and must be ignored in all
other cases. It indicates a specific branch of a VC-4. K=1
indicates that the VC-4 is not further subdivided and contains a
C-4. K=2->4 indicates a specific TUG-3 inside the VC-4. K is not
significant when the AUG-1 is divided into AU-3s.
4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE.
It is not significant for an unstructured VC-4 or STS-1 SPE. L=1 It is not significant for an unstructured VC-4 (L=0). L=1
indicates that the TUG-3/VC-3/STS-1 SPE is not further indicates that the TUG-3/VC-3/STS-1 SPE is not further
subdivided and contains a VC-3/C-3 in SDH or the equivalent in subdivided 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 SONET. L=2->8 indicates a specific TUG-2/VT Group inside the
corresponding higher order signal. corresponding higher order signal.
5. M indicates a specific branch of a TUG-2/VT Group. It is not 5. 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. 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 subdivided M=1 indicates that the TUG-2/VT Group is not further subdivided
and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3 and contains a VC-2/VT-6 SPE. M=2->3 indicates a specific VT-3
inside the corresponding VT Group, these values MUST NOT be used 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 for SDH since there is no equivalent of VT-3 with SDH. M=4->6
indicates a specific VC-12/VT-2 SPE inside the corresponding indicates a specific VC-12/VT-2 SPE inside the corresponding
TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE TUG-2/VT Group. M=7->10 indicates a specific VC-11/VT-1.5 SPE
inside the corresponding TUG-2/VT Group. Note that M=0 denotes inside the corresponding TUG-2/VT Group. Note that M=0 denotes
an unstructured VC-4, VC-3 or STS-1 SPE (easy for debugging). an unstructured VC-4, VC-3 or STS-1 SPE.
E. Mannie Editor Internet-Draft April 2001 10 E. Mannie Editor Internet-Draft June 2002 10
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
The M encoding is summarized in the following table: The M encoding is summarized in the following table:
M SDH SONET M SDH SONET
---------------------------------------------------------- ----------------------------------------------------------
0 unstructured VC-4/VC-3 unstructured STS-1 SPE 0 unstructured VC-4/VC-3 unstructured STS-1 SPE
1 VC-2 VT-6 1 VC-2 VT-6
2 - 1st VT-3 2 - 1st VT-3
3 - 2nd VT-3 3 - 2nd VT-3
4 1st VC-12 1st VT-2 4 1st VC-12 1st VT-2
5 2nd VC-12 2nd VT-2 5 2nd VC-12 2nd VT-2
6 3rd VC-12 3rd VT-2 6 3rd VC-12 3rd VT-2
7 1st VC-11 1st VT-1.5 7 1st VC-11 1st VT-1.5
8 2nd VC-11 2nd VT-1.5 8 2nd VC-11 2nd VT-1.5
9 3rd VC-11 3rd VT-1.5 9 3rd VC-11 3rd VT-1.5
10 4th VC-11 4th VT-1.5 10 4th VC-11 4th VT-1.5
In case of contiguous concatenation, the label that is used is the
lowest label of the contiguously concatenated signal as explained
before. The higher part of the label indicates where the signal
starts and the lowest part is not significant. For instance, when
requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.
Examples of labels: Examples of labels:
Example 1: S>0, U=1, K=1, L=0, M=0 Example 1: S>0, U=1, K=1, L=0, M=0
Denotes the unstructured VC-4 of the Sth AUG-1. Denotes the unstructured VC-4 of the Sth AUG-1.
Example 2: S>0, U=1, K>1, L=1, M=0 Example 2: S>0, U=1, K>1, L=1, M=0
Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1. Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth AUG-1.
Example 3: S>0, U=0, K=0, L=0, M=0 Example 3: S>0, U=0, K=0, L=0, M=0
Denotes the unstructured SPE of the Sth STS-1. Denotes the unstructured SPE of the Sth STS-1.
Example 4: S>0, U=0, K=0, L>1, M=1 Example 4: S>0, U=0, K=0, L>1, M=1
Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1. Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1.
Example 5: S>0, U=0, K=0, L>1, M=9 Example 5: S>0, U=0, K=0, L>1, M=9
Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1. Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1.
In case of contiguous concatenation, the label that is used is the
lowest label of the contiguously concatenated signal as explained
before. The higher part of the label indicates where the signal
starts and the lowest part is not significant. For instance, when
requesting an STS-48c the label is S>0, U=0, K=0, L=0, M=0.
In case of STM-0, the values of S, U and K must be equal to zero
according to the field coding rules. For instance, when requesting
an unstructured VC-3 in an STM-0 the label is S=0, U=0, K=0, L=1,
M=0.
In case of STS-3c SPE, the value of S is the index of the first
STS-1 of the STS-3c SPE in the SONET multiplex where SPEs are
numbered from 1 to N (before any interleaving).
When a transparent concatenated STM-N/STS-3*N (N=1, 4, 16, 64,
256) is requested, the label is coded as for the case of
contiguous concatenation and with S=1. I.e. S=1, U=0, K=0, L=0,
M=0.
E. Mannie Editor Internet-Draft June 2002 11
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
4. Acknowledgments 4. Acknowledgments
Valuable comments and input were received from many people. Valuable comments and input were received from many people.
5. Security Considerations 5. Security Considerations
This draft introduces no new security considerations to either This draft introduces no new security considerations to either
[GMPLS-RSVP] or [GMPLS-LDP]. [GMPLS-RSVP] or [GMPLS-LDP].
E. Mannie Editor Internet-Draft April 2001 11
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
6. References 6. References
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft, Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-05.txt, draft-ietf-mpls-generalized-signaling-07.txt,
July 2001. November 2001.
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling -
CR-LDP Extensions", Internet Draft, CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-04.txt, draft-ietf-mpls-generalized-cr-ldp-05.txt,
July 2001. November 2001.
[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS
Signaling - RSVP-TE Extensions", Internet Draft, Signaling - RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-04.txt, draft-ietf-mpls-generalized-rsvp-te-06.txt,
July 2001. November 2001.
[GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to [GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to
control non-standard SONET and SDH features", control non-standard SONET and SDH features",
Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh- Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-
extensions-00.txt, August 2001. extensions-01.txt, December 2001.
[GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet
Draft, draft-many-gmpls-architecture-00.txt, June Draft, draft-ietf-ccamp-gmpls-architecture-01.txt,
2001. November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997. Services," RFC 2210, September 1997.
7. Authors Addresses 7. Authors Addresses
Stefan Ansorge Stefan Ansorge
Alcatel SEL AG Alcatel
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
Phone: +49 7 11 821 337 44 Phone: +49 7 11 821 337 44
Email: Stefan.ansorge@alcatel.de Email: Stefan.ansorge@alcatel.de
E. Mannie Editor Internet-Draft June 2002 12
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Peter Ashwood-Smith Peter Ashwood-Smith
Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763 4534 Phone: +1 613 763 4534
Email: petera@nortelnetworks.com Email: petera@nortelnetworks.com
E. Mannie Editor Internet-Draft April 2001 12
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1 408 972-3645 Phone: +1 408 972-3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
skipping to change at line 693 skipping to change at line 712
Phone: +1 408 972 3720 Phone: +1 408 972 3720
Email: jdrake@calient.net Email: jdrake@calient.net
Yanhe Fan Yanhe Fan
Axiowave Networks, Inc. Axiowave Networks, Inc.
100 Nickerson Road 100 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
Phone: +1 508 460 6969 Ext. 627 Phone: +1 508 460 6969 Ext. 627
Email: yfan@axiowave.com Email: yfan@axiowave.com
E. Mannie Editor Internet-Draft June 2002 13
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Michele Fontana Michele Fontana
Alcatel TND-Vimercate Alcatel
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-7053 Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it Email: michele.fontana@netit.alcatel.it
E. Mannie Editor Internet-Draft April 2001 13
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
Gert Grammel Gert Grammel
Alcatel TND-Vimercate Alcatel
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-7060 Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it Email: gert.grammel@netit.alcatel.it
Juergen Heiles Juergen Heiles
Siemens AG Siemens AG
Hofmannstr. 51 Hofmannstr. 51
D-81379 Munich, Germany D-81379 Munich, Germany
Phone: +49 89 7 22 - 4 86 64 Phone: +49 89 7 22 - 4 86 64
skipping to change at line 745 skipping to change at line 764
Zhi-Wei Lin Zhi-Wei Lin
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733-3030 Holmdel, NJ 07733-3030
Phone: +1 732 949 5141 Phone: +1 732 949 5141
Email: zwlin@lucent.com Email: zwlin@lucent.com
Ben Mack-Crane Ben Mack-Crane
Tellabs Tellabs
Email: Ben.Mack-Crane@tellabs.com Email: Ben.Mack-Crane@tellabs.com
E. Mannie Editor Internet-Draft June 2002 14
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Eric Mannie Eric Mannie
EBONE EBONE
Terhulpsesteenweg 6A Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium 1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52 Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52 Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18 Fax: +32 2 658 51 18
Email: eric.mannie@ebone.com Email: eric.mannie@ebone.com
E. Mannie Editor Internet-Draft April 2001 14
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
Dimitri Papadimitriou Dimitri Papadimitriou
Senior R&D Engineer - Optical Networking Alcatel
Alcatel IPO-NSG
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be Email: Dimitri.Papadimitriou@alcatel.be
Mike Raftelis Mike Raftelis
White Rock Networks White Rock Networks
18111 Preston Road Suite 900 18111 Preston Road Suite 900
Dallas, TX 75252 Dallas, TX 75252
Phone: +1 (972)588-3728 Phone: +1 (972)588-3728
skipping to change at line 801 skipping to change at line 819
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: dsaha@tellium.com Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
Metanoia, Inc. Metanoia, Inc.
335 Elan Village Lane 335 Elan Village Lane
San Jose, CA 95134 San Jose, CA 95134
Phone: +1 408 943 1794 Phone: +1 408 943 1794
Email: vsharma87@yahoo.com Email: vsharma87@yahoo.com
E. Mannie Editor Internet-Draft June 2002 15
draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Voice: +1 978 244 8143 Voice: +1 978 244 8143
Email: swallow@cisco.com Email: swallow@cisco.com
E. Mannie Editor Internet-Draft April 2001 15
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
Z. Bo Tang Z. Bo Tang
Tellium, Inc. Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4231 Phone: +1 732 923 4231
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Eve Varma Eve Varma
skipping to change at line 837 skipping to change at line 855
Botterstraat 45 Botterstraat 45
Postbus 18 Postbus 18
1270 AA Huizen, Netherlands 1270 AA Huizen, Netherlands
Email: mvissers@lucent.com Email: mvissers@lucent.com
Yangguang Xu Yangguang Xu
21-2A41, 1600 Osgood Street 21-2A41, 1600 Osgood Street
North Andover, MA 01845 North Andover, MA 01845
Email: xuyg@lucent.com Email: xuyg@lucent.com
E. Mannie Editor Internet-Draft April 2001 16 E. Mannie Editor Internet-Draft June 2002 16
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Appendix 1 - Signal Type Values Extension For Group Signals
This appendix defines the following optional additional Signal
Type values for the Signal Type field of section 2.1:
Value Type
----- ---------------------
13 VTG / TUG-2
14 TUG-3
15 STSG-3 / AUG-1
16 STSG-12 / AUG-4
17 STSG-48 / AUG-16
18 STSG-192 / AUG-64
19 STSG-768 / AUG-256
Administrative Unit Group-Ns (AUG-Ns) and STS Groups-3*Ns (STSG-Ms),
are logical objects that are a collection of AU-3s/STS-1 SPEs, AU-
4s/STS-3c SPEs and/or AU-4-Xcs/STS-3*Xc SPEs (X = 4,16,64,256).
When used as a signal type this means that all the VC-3s/STS-1_SPEs,
VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc SPEs in the AU-3s/STS-1 SPEs,
AU-4s/STS-3c SPEs or AU-4-Xcs/STS-3*Xc SPEs that comprise the AUG-
N/STSG-3*N are switched together as one unique signal.
In addition the structure of the VC-3s/STS-1_SPEs, VC-4s/STS-3c_SPEs
or VC-4-Xcs/STS-3*Xc_SPEs in the AUG-N/STSG-3*N are preserved and are
allowed to change over the life of an AUG-N/STSG-3*N.
It is this flexibility in the relationships between the component VCs
or SPEs that differentiates this signal from a set of VC-3s/STS-
1_SPEs, VC-4s/STS-3c_SPEs or VC-4-Xcs/STS-3*Xc_SPEs. Whether the AUG-
N/STSG-3*N is structured with AU-3s/STS-1 SPEs, AU-4s/STS-3c SPEs
and/or AU-4-Xcs/STS-3*Xc SPEs does not need to be specified and is
allowed to change over time. The same reasoning applies to TUG-2/VTG
and TUG-3 signal types.
For example an STSG-48 could at one time consist of four STS-12c
signals and at another point in time of three STS-12c signals and
four STS-3c signals.
Note that the use of TUG-X, AUG-N and STSG-M as circuit types is not
described in ANSI and ITU-T standards. The use of these signal types
in the signaling plane is conceptual.
These signal types are conceptual objects that intend to designate
a group of physical objects in the standardized data plane.
E. Mannie Editor Internet-Draft April 2001 17
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001
Appendix 2 - Signal Type Values Extension For VC-3 Appendix 1 - Signal Type Values Extension For VC-3
This appendix defines the following optional additional Signal This appendix defines the following optional additional Signal
Type value for the Signal Type field of section 2.1: Type value for the Signal Type field of section 2.1:
Value Type Value Type
----- --------------------- ----- ---------------------
20 "VC-3 via AU-3 at the end" 20 "VC-3 via AU-3 at the end"
According to the G.707 standard a VC-3 in the TU-3/TUG-3/VC-4/AU-4 According to the G.707 standard a VC-3 in the TU-3/TUG-3/VC-4/AU-4
branch of the SDH multiplex cannot be structured in TUG-2s, branch of the SDH multiplex cannot be structured in TUG-2s,
skipping to change at line 928 skipping to change at line 896
type. This information can be used, for instance, by the type. This information can be used, for instance, by the
penultimate LSR to switch an incoming VC-3 received in any branch penultimate LSR to switch an incoming VC-3 received in any branch
to the TU-3 branch on the outgoing interface to the destination to the TU-3 branch on the outgoing interface to the destination
LSR. LSR.
The "VC-3 via AU-3 at the end" signal type does not imply that the The "VC-3 via AU-3 at the end" signal type does not imply that the
VC-3 must be switched via the AU-3 branch at some other places in VC-3 must be switched via the AU-3 branch at some other places in
the network. The VC-3 signal type just indicates that a VC-3 in the network. The VC-3 signal type just indicates that a VC-3 in
any branch is suitable. any branch is suitable.
E. Mannie Editor Internet-Draft April 2001 18 E. Mannie Editor Internet-Draft June 2002 17
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
Annex 1 - Examples Annex 1 - Examples
This annex defines examples of SONET and SDH signal coding. Their This annex defines examples of SONET and SDH signal coding. Their
objective is to help the reader to understand how works the traffic objective is to help the reader to understand how works the traffic
parameter coding and not to give examples of typical SONET or SDH parameter coding and not to give examples of typical SONET or SDH
signals. signals.
As stated above, signal types are Elementary Signals to which As stated above, signal types are Elementary Signals to which
successive concatenation, multiplication and transparency successive concatenation, multiplication and transparency
skipping to change at line 986 skipping to change at line 954
8. An STS-3c SPE signal is formed by the application of RCC with 8. An STS-3c SPE signal is formed by the application of RCC with
value 0 (no contiguous concatenation), NCC with value 0, NVC with value 0 (no contiguous concatenation), NCC with value 0, NVC with
value 0, MT with value 1 and T with value 0 to an STS-3c SPE value 0, MT with value 1 and T with value 0 to an STS-3c SPE
Elementary Signal. Elementary Signal.
9. An STS-48c SPE signal is formed by the application of RCC with 9. An STS-48c SPE signal is formed by the application of RCC with
flag 1 (standard contiguous concatenation), NCC with value 16, NVC flag 1 (standard contiguous concatenation), NCC with value 16, NVC
with value 0, MT with value 1 and T with value 0 to an STS-3c SPE with value 0, MT with value 1 and T with value 0 to an STS-3c SPE
Elementary Signal. Elementary Signal.
E. Mannie Editor Internet-Draft April 2001 19 E. Mannie Editor Internet-Draft June 2002 18
draft-ietf-ccamp-gmpls-sonet-sdh-02.txt October, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-03.txt December, 2001
10. An STS-1-3v SPE signal is formed by the application of RCC 10. An STS-1-3v SPE signal is formed by the application of RCC
with value 0, NVC with value 3 (virtual concatenation of 3 with value 0, NVC with value 3 (virtual concatenation of 3
components), MT with value 1 and T with value 0 to an STS-1 SPE components), MT with value 1 and T with value 0 to an STS-1 SPE
Elementary Signal. Elementary Signal.
11. An STS-3c-9v SPE signal is formed by the application of RCC 11. An STS-3c-9v SPE signal is formed by the application of RCC
with value 0, NCC with value 0, NVC with value 9 (virtual with value 0, NCC with value 0, NVC with value 9 (virtual
concatenation of 9 STS-3c), MT with value 1 and T with value 0 to concatenation of 9 STS-3c), MT with value 1 and T with value 0 to
an STS-3c SPE Elementary Signal. an STS-3c SPE Elementary Signal.
skipping to change at line 1011 skipping to change at line 979
MT with value 1 and T with flag 1 to an STS-12 Elementary Signal. MT with value 1 and T with flag 1 to an STS-12 Elementary Signal.
13. 3 x STS-768c SPE signal is formed by the application of RCC 13. 3 x STS-768c SPE signal is formed by the application of RCC
with flag 1, NCC with value 256, NVC with value 0, MT with value with flag 1, NCC with value 256, NVC with value 0, MT with value
3, and T with value 0 to an STS-3c SPE Elementary Signal. 3, and T with value 0 to an STS-3c SPE Elementary Signal.
14. 5 x VC-4-13v composed signal is formed by the application of 14. 5 x VC-4-13v composed signal is formed by the application of
RCC with value 0, NVC with value 13, MT with value 5 and T with RCC with value 0, NVC with value 13, MT with value 5 and T with
value 0 to a VC-4 Elementary Signal. value 0 to a VC-4 Elementary Signal.
E. Mannie Editor Internet-Draft April 2001 20 E. Mannie Editor Internet-Draft June 2002 19
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/