draft-ietf-ccamp-gmpls-sonet-sdh-04.txt   draft-ietf-ccamp-gmpls-sonet-sdh-05.txt 
CCAMP Working Group Eric Mannie - Editor (KPNQwest) CCAMP Working Group Eric Mannie (KPNQwest) - Editor
Internet Draft Internet Draft Dimitri Papadimitriou (Alcatel) - Editor
Expiration Date: October 2002 Stefan Ansorge (Alcatel) Expiration Date: December 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)
Suresh Katukam (Cisco) Suresh Katukam (Cisco)
Kireeti Kompella (Juniper) Kireeti Kompella (Juniper)
Jonathan P. Lang (Calient) Jonathan P. Lang (Calient)
Fong Liaw (Zaffire) Fong Liaw (Solas)
Zhi-Wei Lin (Lucent) Zhi-Wei Lin (Lucent)
Ben Mack-Crane (Tellabs) Ben Mack-Crane (Tellabs)
Dimitri Papadimitriou (Alcatel)
Dimitrios Pendarakis (Tellium) Dimitrios Pendarakis (Tellium)
Mike Raftelis (White Rock) Mike Raftelis (White Rock)
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)
April 2002 June 2002
GMPLS Extensions for SONET and SDH Control Generalized Multiprotocol Label Switching Extensions for
SONET and SDH Control
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt draft-ietf-ccamp-gmpls-sonet-sdh-05.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 Mannie & Papadimitriou Editors 1
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html
Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
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 Multiprotocol
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It defines Label Switching (GMPLS) signaling. It defines the SONET/SDH
the SONET/SDH technology specific information needed when using 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 four new classes of interfaces and switching: include support of four new classes of interfaces and switching:
Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM),
Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). A
functional description of the extensions to MPLS signaling needed functional description of the extensions to MPLS signaling needed
to support the new classes of interfaces and switching is provided to support the new classes of interfaces and switching is provided
skipping to change at line 88 skipping to change at line 90
and mechanisms needed to support all five classes of interfaces, and mechanisms needed to support all five classes of interfaces,
and CR-LDP extensions can be found in [GMPLS-LDP]. This document and CR-LDP extensions can be found in [GMPLS-LDP]. This document
presents details that are specific to SONET/SDH. Per [GMPLS-SIG], presents details that are specific to SONET/SDH. Per [GMPLS-SIG],
SONET/SDH specific parameters are carried in the signaling SONET/SDH specific parameters are carried in the signaling
protocol in traffic parameter specific 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. SONET and SDH 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
respectively. respectively.
These traffic parameters specify indeed a base set of capabilities These traffic parameters specify indeed a base set of capabilities
for SONET (ANSI T1.105) and SDH (ITU-T G.707) such as for SONET (ANSI T1.105) and SDH (ITU-T G.707) such as
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 October 2002 2 Mannie & Papadimitriou Editors Internet-Draft December 2002 2
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 157 skipping to change at line 159
- 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 October 2002 3 Mannie & Papadimitriou Editors Internet-Draft December 2002 3
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 214 skipping to change at line 216
scope. A downstream node that doesnĘt support any of the scope. A downstream node that doesnĘt support any of the
concatenation types indicated by the field must refuse the LSP concatenation types indicated by the field must refuse the LSP
request. In particular, it must refuse the LSP request if it request. In particular, it must refuse the LSP request if it
doesnĘt support contiguous concatenation at all. doesnĘt support contiguous concatenation at all.
The upstream node knows 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 October 2002 4 Mannie & Papadimitriou Editors Internet-Draft December 2002 4
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 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.
skipping to change at line 267 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 October 2002 5 Mannie & Papadimitriou Editors Internet-Draft December 2002 5
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 325 skipping to change at line 327
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 signaling specification, is only applicable to the fields in
the 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 October 2002 6 Mannie & Papadimitriou Editors Internet-Draft December 2002 6
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 382 skipping to change at line 384
Profile (P) Profile (P)
This field is intended to indicate particular capabilities that This field is intended to indicate particular capabilities that
must be supported for the LSP, for example monitoring must be supported for the LSP, for example monitoring
capabilities. capabilities.
No standard profile is currently defined and this field SHOULD No standard profile is currently defined and this field SHOULD
be set to zero when transmitted and SHOULD be ignored when be set to zero when transmitted and SHOULD be ignored when
received. received.
E. Mannie Editor Internet-Draft October 2002 7 Mannie & Papadimitriou Editors Internet-Draft December 2002 7
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
In the future TLV based extensions may be created. In the future TLV based extensions may be created.
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
content of the objects is defined above in Section 2.1. The content 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:
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 = TBA (by IANA)
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (TBA) SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (by IANA)
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].
For a particular sender in a session the contents of the FLOWSPEC For a particular sender in a session the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the object received in a Resv message SHOULD be identical to the
contents of the SENDER_TSPEC object received in the corresponding contents of the SENDER_TSPEC object received in the corresponding
Path message. If the objects do not match, a ResvErr message with Path message. If the objects do not match, a ResvErr message with
skipping to change at line 425 skipping to change at line 427
SONET/SDH Traffic Parameters TLV. The content of the TLV is SONET/SDH Traffic Parameters TLV. The content of the TLV is
defined above in Section 2.1. The header of the TLV has the defined above in Section 2.1. The header of the TLV has the
following format: following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field for the SONET/SDH Traffic Parameters TLV is: 0xTBA. The type field for the SONET/SDH Traffic Parameters TLV is: TBA
(by IANA).
Mannie & Papadimitriou Editors Internet-Draft December 2002 8
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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
within an ingress port and time-slots within an egress port, i.e. within an ingress port and time-slots within an egress port, i.e.
a VC-x, a VT-x SPE or an STS-x SPE. An SDH/SONET label will a VC-x, a VT-x SPE or an STS-x SPE. An SDH/SONET label will
E. Mannie Editor Internet-Draft October 2002 8
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
identify the exact position (i.e. first time-slot) of a particular identify the exact position (i.e. first time-slot) of a particular
VC-x, VT-x SPE or STS-x SPE signal in a multiplexing structure. VC-x, VT-x SPE or STS-x SPE signal in a multiplexing structure.
SDH and SONET labels are carried in the Generalized Label per SDH and SONET labels are carried in the Generalized Label per
[GMPLS-RSVP] and [GMPLS-LDP]. [GMPLS-RSVP] and [GMPLS-LDP].
Note that by time-slots we mean the time-slots as they appear Note that by time-slots we mean the time-slots as they appear
logically and sequentially in the multiplex, not as they appear logically and sequentially in the multiplex, not as they appear
after any possible interleaving. after any possible interleaving.
These multiplexing structures will be used as naming trees to These multiplexing structures will be used as naming trees to
skipping to change at line 484 skipping to change at line 486
restriction compared to the G.707/T1.105 recommendations. restriction compared to the G.707/T1.105 recommendations.
The standard definition for virtual concatenation allows each The standard definition for virtual concatenation allows each
virtual concatenation components to travel over diverse paths. virtual concatenation components to travel over diverse paths.
Within GMPLS, virtual concatenation components must travel over Within GMPLS, virtual concatenation components must travel over
the same (component) link if they are part of the same LSP. This the same (component) link if they are part of the same LSP. This
is due to the way that labels are bound to a (component) link. is due to the way that labels are bound to a (component) link.
Note however, that the routing of components on different paths is Note however, that the routing of components on different paths is
indeed equivalent to establishing different LSPs, each one having indeed equivalent to establishing different LSPs, each one having
its own route. Several LSPs can be initiated and terminated its own route. Several LSPs can be initiated and terminated
Mannie & Papadimitriou Editors Internet-Draft December 2002 9
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
between the same nodes and their corresponding components can then between the same nodes and their corresponding components can then
be associated together (i.e. virtually concatenated). be associated together (i.e. virtually concatenated).
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 time- concatenated signals, the first set of labels indicates the time-
slots occupied by the first virtually concatenated signal, the slots occupied by the first virtually concatenated signal, the
second set of labels indicates the time-slots occupied by the second set of labels indicates the time-slots occupied by the
second virtually concatenated signal, and so on. The above second virtually concatenated signal, and so on. The above
E. Mannie Editor Internet-Draft October 2002 9
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
representation limits multiplication to remain within a single representation limits multiplication to remain within a single
(component) link. (component) link.
The format of the label for SDH and/or SONET TDM-LSR link is: The format of the label for SDH and/or SONET TDM-LSR link is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 542 skipping to change at line 544
order LSP is unknown or not relevant, the lowest part of that order LSP is unknown or not relevant, the lowest part of that
label is non-significant and is set to zero, i.e. the label is label is non-significant and is set to zero, i.e. the label is
"S,U,K,0,0". "S,U,K,0,0".
For instance, a VC-3 LSP can be used to carry lower order LSPs. In For instance, a VC-3 LSP can be used to carry lower order LSPs. In
that case the labels allocated between the two ends of the VC-3 that case the labels allocated between the two ends of the VC-3
LSP for the lower order LSPs will have S, U and K set to zero, LSP for the lower order LSPs will have S, U and K set to zero,
i.e., non-significant, while L and M will be used to indicate the i.e., non-significant, while L and M will be used to indicate the
signal allocated in that VC-3. signal allocated in that VC-3.
Mannie & Papadimitriou Editors Internet-Draft December 2002 10
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
In case of tunneling such as VC-4 containing VC-3 containing VC- In case of tunneling such as VC-4 containing VC-3 containing VC-
12/VC-11 where the SUKLM structure is not adequate to represent 12/VC-11 where the SUKLM structure is not adequate to represent
the full signal structure, a hierarchical approach must be used, the full signal structure, a hierarchical approach must be used,
i.e. per layer network signaling. i.e. per layer network signaling.
E. Mannie Editor Internet-Draft October 2002 10
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
The possible values of S, U, K, L and M are defined as follows: The possible values of S, U, K, L and M are defined as follows:
1. S=1->N is the index of a particular AUG-1/STS-3 inside an 1. S=1->N is the index of a particular AUG-1/STS-3 inside an
STM-N/STS-N multiplex. S is only significant for SDH STM-N (N>0) STM-N/STS-N multiplex. S is only significant for SDH STM-N (N>0)
and SONET STS-N (N>1) and must be 0 and ignored for STM-0 and and SONET STS-N (N>1) and must be 0 and ignored for STM-0 and
STS-1. STS-1.
2. U=1->3 is the index of a particular VC-3/STS-1 SPE within an 2. U=1->3 is the index of a particular VC-3/STS-1 SPE within an
AUG-1/STS-3. U is only significant for SDH STM-N (N>0) and SONET AUG-1/STS-3. U is only significant for SDH STM-N (N>0) and SONET
STS-N (N>1) and must be 0 and ignored for STM-0 and STS-1. STS-N (N>1) and must be 0 and ignored for STM-0 and STS-1.
skipping to change at line 594 skipping to change at line 596
S SDH SONET S SDH SONET
------------------------------------------------ ------------------------------------------------
0 other other 0 other other
1 1st AUG-1 1st STS-3 1 1st AUG-1 1st STS-3
2 2nd AUG-1 2nd STS-3 2 2nd AUG-1 2nd STS-3
3 3rd AUG-1 3rd STS-3 3 3rd AUG-1 3rd STS-3
4 4rd AUG-1 4rd STS-3 4 4rd AUG-1 4rd STS-3
: : : : : :
N Nth AUG-1 Nth STS-3 N Nth AUG-1 Nth STS-3
Mannie & Papadimitriou Editors Internet-Draft December 2002 11
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
The U encoding is summarized in the following table: The U encoding is summarized in the following table:
U SDH AUG-1 SONET STS-3 U SDH AUG-1 SONET STS-3
------------------------------------------------- -------------------------------------------------
0 other other 0 other other
1 1st VC-3 1st STS-1 SPE 1 1st VC-3 1st STS-1 SPE
2 2nd VC-3 2nd STS-1 SPE 2 2nd VC-3 2nd STS-1 SPE
3 3rd VC-3 3rd STS-1 SPE 3 3rd VC-3 3rd STS-1 SPE
E. Mannie Editor Internet-Draft October 2002 11
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
The K encoding is summarized in the following table: The K encoding is summarized in the following table:
K SDH VC-4 K SDH VC-4
--------------- ---------------
0 other 0 other
1 1st TUG-3 1 1st TUG-3
2 2nd TUG-3 2 2nd TUG-3
3 3rd TUG-3 3 3rd TUG-3
The L encoding is summarized in the following table: The L encoding is summarized in the following table:
skipping to change at line 651 skipping to change at line 653
9 4th VC-11 4th VT-1.5 SPE 9 4th VC-11 4th VT-1.5 SPE
Examples of labels: Examples of labels:
Example 1: the label for the VC-4/STS-3c in the Sth AUG-1/STS-3 Example 1: the label for the VC-4/STS-3c in the Sth AUG-1/STS-3
is: S>0, U=0, K=0, L=0, M=0. is: S>0, U=0, K=0, L=0, M=0.
Example 2: the label for the VC-3 within the Kth-1 TUG-3 within Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0. the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
Mannie & Papadimitriou Editors Internet-Draft December 2002 12
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
Example 3: the label for the Uth-1 VC-3/STS-1 SPE within the Sth Example 3: the label for the Uth-1 VC-3/STS-1 SPE within the Sth
AUG-1/STS-3 is: S>0, U>0, K=0, L=0, M=0. AUG-1/STS-3 is: S>0, U>0, K=0, L=0, M=0.
Example 4: the label for the VC-2/VT-6 in the Lth-1 TUG-2/VT Group Example 4: the label for the VC-2/VT-6 in the Lth-1 TUG-2/VT Group
in the Uth-1 VC-3/STS-1 SPE within the Sth AUG-1/STS-3 is: S>0, in the Uth-1 VC-3/STS-1 SPE within the Sth AUG-1/STS-3 is: S>0,
U>0, K=0, L>0, M=0. U>0, K=0, L>0, M=0.
E. Mannie Editor Internet-Draft October 2002 12
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Example 5: the label for the 3rd VC-11/VT-1.5 in the Lth-1 TUG- Example 5: the label for the 3rd VC-11/VT-1.5 in the Lth-1 TUG-
2/VT Group within the Uth-1 VC-3/STS-1 SPE within the Sth AUG- 2/VT Group within the Uth-1 VC-3/STS-1 SPE within the Sth AUG-
1/STS-3 is: S>0, U>0, K=0, L>0, M=8. 1/STS-3 is: S>0, U>0, K=0, L>0, M=8.
Example 6: the label for the VC-4-4c/STS-12c which uses the 9th Example 6: the label for the VC-4-4c/STS-12c which uses the 9th
AUG-1/STS-3 as its first timeslot is: S=9, U=0, K=0, L=0, M=0. AUG-1/STS-3 as its first timeslot is: S=9, U=0, K=0, L=0, M=0.
In case of contiguous concatenation, the label that is used is the In case of contiguous concatenation, the label that is used is the
lowest label of the contiguously concatenated signal as explained lowest label of the contiguously concatenated signal as explained
before. The higher part of the label indicates where the signal before. The higher part of the label indicates where the signal
skipping to change at line 688 skipping to change at line 690
When a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is When a transparent STM-N/STS-3*N (N=1, 4, 16, 64, 256) is
requested, the label is not applicable and is set to zero. requested, the label is not applicable and is set to zero.
Refer to [GMPLS-SONET-SDH-EXT] for the label for the extended set Refer to [GMPLS-SONET-SDH-EXT] for the label for the extended set
of transparency types beyond the transparency types as defined in of transparency types beyond the transparency types as defined in
T1.105/G.707. T1.105/G.707.
4. Acknowledgments 4. Acknowledgments
Valuable comments and input were received from many people, and Valuable comments and input were received from the CCAMP mailing
particularly on the CCAMP mailing list where outstanding list where outstanding discussions took place.
discussions took place.
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 security is described in [GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in
section 11 of [GMPLS-SIG], in [CR-LDP] and in [RSVP-TE]. section 11 of [GMPLS-SIG], in [CR-LDP] and in [RSVP-TE].
6. References 6. IANA Considerations
[GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Three values have to be defined by IANA for this document (two
Signaling Functional Description", Internet Draft, RSVP C-Types and one LDP TLV Type):
draft-ietf-mpls-generalized-signaling-07.txt,
November 2001.
[GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = TBA (see
CR-LDP Extensions", Internet Draft, section 2.2).
draft-ietf-mpls-generalized-cr-ldp-05.txt,
November 2001.
[GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Mannie & Papadimitriou Editors Internet-Draft December 2002 13
Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
E. Mannie Editor Internet-Draft October 2002 13 - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (see
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 section 2.2).
- A type field for the SONET/SDH Traffic Parameters TLV (see
section 2.3).
draft-ietf-mpls-generalized-rsvp-te-06.txt, 7. Intellectual Property Notice
November 2001.
[GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS extensions to The IETF takes no position regarding the validity or scope of any
control non-standard SONET and SDH features", intellectual property or other rights that might be claimed to
Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh- pertain to the implementation or use of the technology described in
extensions-02.txt, April 2002. this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
[GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet The IETF invites any interested party to bring to its attention any
Draft, draft-ietf-ccamp-gmpls-architecture-02.txt, copyrights, patents or patent applications, or other proprietary
March 2002. rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Normative References
[GMPLS-SIG] Berger, L. et al., "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-08.txt,
April 2002.
[GMPLS-LDP] Ashwood-Smith, P., Berger, L. et al., "Generalized
MPLS Signaling - CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-06.txt,
April 2002.
[GMPLS-RSVP] Berger, L. et al, "Generalized MPLS
Signaling - RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-07.txt,
April 2002.
[CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP",
RFC3212, January, 2002. RFC3212, January, 2002.
[RSVP-TE] Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
Mannie & Papadimitriou Editors Internet-Draft December 2002 14
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
9. Informative References
[GMPLS-SONET-SDH-EXT] Mannie, E., Papadimitriou D. et al.,
"Generalized Multiprotocol Label Switching extensions
to control non-standard SONET and SDH features",
Internet Draft,
draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt,
June 2002.
[GMPLS-ARCH] Mannie, E., Papadimitriou D. et al., " Generalized
Multiprotocol Label Switching Architecture",
Internet Draft,
draft-ietf-ccamp-gmpls-architecture-02.txt,
March 2002.
[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 10. Contributors
Services," RFC 2210, September 1997.
7. Authors Addresses Contributors are listed by alphabetical order.
Stefan Ansorge Stefan Ansorge
Alcatel 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
Peter Ashwood-Smith Peter Ashwood-Smith
skipping to change at line 769 skipping to change at line 815
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
Suite 615 Suite 615
E. Mannie Editor Internet-Draft October 2002 14
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Mannie & Papadimitriou Editors Internet-Draft December 2002 15
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
Email: lberger@movaz.com Email: lberger@movaz.com
Greg Bernstein Greg Bernstein
Ciena Corporation Ciena Corporation
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 94014 Cupertino, CA 94014
Phone: +1 408 366 4713 Phone: +1 408 366 4713
Email: greg@ciena.com Email: greg@ciena.com
Angela Chiu Angela Chiu
skipping to change at line 826 skipping to change at line 872
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
Email: Juergen.Heiles@icn.siemens.de Email: Juergen.Heiles@icn.siemens.de
E. Mannie Editor Internet-Draft October 2002 15
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Suresh Katukam Suresh Katukam
Cisco Systems Cisco Systems
1450 N. McDowell Blvd, 1450 N. McDowell Blvd,
Mannie & Papadimitriou Editors Internet-Draft December 2002 16
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
Petaluma, CA 94954-6515 USA Petaluma, CA 94954-6515 USA
e-mail: skatukam@cisco.com e-mail: skatukam@cisco.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117
Email: jplang@calient.net Email: jplang@calient.net
Fong Liaw
Solas Research
Email: fongliaw@yahoo.com
Zhi-Wei Lin Zhi-Wei Lin
Lucent Lucent
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
Eric Mannie Editor & Primary Point of Contact
KPNQwest
Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18
Email: eric.mannie@kpnqwest.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Dimitrios Pendarakis Dimitrios Pendarakis
Tellium Tellium
Phone: +1 (732) 923-4254 Phone: +1 (732) 923-4254
Email: dpendarakis@tellium.com Email: dpendarakis@tellium.com
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
E. Mannie Editor Internet-Draft October 2002 16
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Phone: +1 (972)588-3728 Phone: +1 (972)588-3728
Fax: +1 (972)588-3701 Fax: +1 (972)588-3701
Email: Mraftelis@WhiteRockNetworks.com Email: Mraftelis@WhiteRockNetworks.com
Bala Rajagopalan Bala Rajagopalan
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 4237 Phone: +1 732 923 4237
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: braja@tellium.com Email: braja@tellium.com
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Mannie & Papadimitriou Editors Internet-Draft December 2002 17
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
Email: yakov@juniper.net Email: yakov@juniper.net
Debanjan Saha Debanjan Saha
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901
Phone: +1 732 923 4264 Phone: +1 732 923 4264
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: dsaha@tellium.com Email: dsaha@tellium.com
skipping to change at line 942 skipping to change at line 977
Fax: +1 732 923 9804 Fax: +1 732 923 9804
Email: btang@tellium.com Email: btang@tellium.com
Eve Varma Eve Varma
Lucent Lucent
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733-3030 Holmdel, NJ 07733-3030
Phone: +1 732 949 8559 Phone: +1 732 949 8559
Email: evarma@lucent.com Email: evarma@lucent.com
E. Mannie Editor Internet-Draft October 2002 17
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001
Maarten Vissers Maarten Vissers
Lucent Lucent
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
Lucent Lucent
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 October 2002 18 Mannie & Papadimitriou Editors Internet-Draft December 2002 18
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
11. Editors
Eric Mannie
KPNQwest
Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium
Phone: +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax: +32 2 658 51 18
Email: eric.mannie@kpnqwest.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
12. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Mannie & Papadimitriou Editors Internet-Draft December 2002 19
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
Appendix 1 - 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"
skipping to change at line 999 skipping to change at line 1080
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 AU-3 branch on the outgoing interface to the destination to the AU-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 October 2002 19 Mannie & Papadimitriou Editors Internet-Draft December 2002 20
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 1056 skipping to change at line 1137
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 October 2002 20 Mannie & Papadimitriou Editors Internet-Draft December 2002 21
draft-ietf-ccamp-gmpls-sonet-sdh-04.txt April, 2001 draft-ietf-ccamp-gmpls-sonet-sdh-05.txt June, 2002
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 1101 skipping to change at line 1182
STM-256 MS transparent 12 0 0 0 1 2 STM-256 MS transparent 12 0 0 0 1 2
STS-1 SPE 5 0 0 0 1 0 STS-1 SPE 5 0 0 0 1 0
STS-3c SPE 6 0 0 0 1 0 STS-3c SPE 6 0 0 0 1 0
STS-48c SPE 6 1 16 0 1 0 STS-48c SPE 6 1 16 0 1 0
STS-1-3v SPE 5 0 0 3 1 0 STS-1-3v SPE 5 0 0 3 1 0
STS-3c-9v SPE 6 0 0 9 1 0 STS-3c-9v SPE 6 0 0 9 1 0
STS-12 Section transparent 9 0 0 0 1 1 STS-12 Section transparent 9 0 0 0 1 1
3 x STS-768c SPE 6 1 256 0 3 0 3 x STS-768c SPE 6 1 256 0 3 0
5 x VC-4-13v 6 0 0 13 5 0 5 x VC-4-13v 6 0 0 13 5 0
E. Mannie Editor Internet-Draft October 2002 21 Mannie & Papadimitriou Editors Internet-Draft December 2002 22
 End of changes. 

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