label space supports the sub-levels of ODUk multiplexing. ODUk
multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk
(k > j), in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e., an
ODTUG constituted by ODU tributary slots) that is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk, and the ODUk is
mapped into an OTUk.
Therefore, the label space structure is a tree whose root is an OTUk
signal and whose leaves are the ODUj signals (k >= j) that can be
transported via the tributary slots and switched between these slots.
A G.709 Digital Path layer label identifies the exact position of a
particular ODUj signal in an ODUk multiplexing structure.
The G.709 Digital Path Layer label or ODUk label has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits MUST be set to zero when sent and SHOULD be ignored
when received.
The specification of the fields t1, t2, and t3 self-consistently
characterizes the ODUk label space. The value space for the t1, t2,
and t3 fields is defined as follows:
1. t1 (1-bit):
- t1=1 indicates an ODU1 signal.
- t1 is not significant for the other ODUk signal types (i.e.,
t1 value MUST be set to 0 and ignored).
2. t2 (3-bit):
- t2=1 indicates an ODU2 signal that is not further sub-
divided.
- t2=[2..5] indicates the tributary slot (t2th-2) used by the
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
- t2 is not significant for an ODU3 (i.e., t2 value MUST be
set to 0 and ignored).
3. t3 (6-bit):
- t3=1 indicates an ODU3 signal that is not further sub-
divided.
- t3=[2..17] indicates the tributary slot (t3th-1) used by the
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
- t3=[18..33] indicates the tributary slot (t3th-17) used by
the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
to identify the 4 tributary slots used by the ODU2; these tributary
time slots have to be allocated in ascending order.
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j
> i), the corresponding ODUk signal ODU[i] is directly mapped into
the corresponding OTUk signal (k=i). This is referred to as the
mapping of an ODUk signal into an OTUk of the same order. Therefore,
the numbering starts at 1; zero is used to indicate a non-significant
field. A label field equal to zero is an invalid value.
Examples:
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
- t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot
of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
- t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot
of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
4.2. Label Distribution Rules
In case of ODUk in OTUk mapping, only one label can appear in the
Generalized Label. The unique label is encoded as a single 32-bit
label value (as defined in Section 4.1) of the GENERALIZED_LABEL
object (Class-Num = 16, C-Type = 2).
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
list of the labels in the multiplex is given (this list can be
restricted to only one label when NMC = 1). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots). This ordered list of
labels is encoded as a sequence of 32-bit label values (as defined in
Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type
= 2).
In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a
component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link. In case of
multiplexed virtually concatenated signals, the first set of labels
indicates the components (ODUj tributary slots) of the first
virtually concatenated signal, the second set of labels indicates the
components (ODUj tributary slots) of the second virtually
concatenated signal, and so on. This ordered list of labels is
encoded as a sequence of 32-bit label values (as defined in Section
4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
In case of ODUk virtual concatenation, the number of label values is
determined by the NVC value. Multiplexed ODUk virtual concatenation
additionally uses the NMC value to determine the number of labels per
set (equal in size).
In case of multiplication (i.e., when using the MT field), the
explicit ordered list of all labels taking part in the composed
signal is given. The above representation limits multiplication to
remain within a single (component) link. In case of multiplication
of multiplexed virtually concatenated signals, the first set of
labels indicates the components of the first multiplexed virtually
concatenated signal, the second set of labels indicates components of
the second multiplexed virtually concatenated signal, and so on.
This ordered list of labels is encoded as a sequence of 32-bit label
values (as defined in Section 4.1) of the GENERALIZED_LABEL object
(Class-Num = 16, C-Type = 2). In case of multiplication of (equal)
ODUk virtual concatenated signals, the number of label values per
signal is determined by the NVC value. Multiplication of multiplexed
(equal) ODUk virtual concatenation additionally uses the NMC value to
determine the number of labels per set (equal in size).
4.3. Optical Channel Label Space
At the Optical Channel layer, the label space must be consistently
defined as a flat space whose values reflect the local assignment of
OCh identifiers that correspond to the OTM-n.m sub-interface signals
(m = 1, 2 or 3). Note that these identifiers do not cover OChr
because the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not defined in [ITUT-G798].
The OCh label space values are defined by either absolute values
(i.e., channel identifiers or Channel ID, also referred to as
wavelength identifiers) or relative values (channel spacing, also
referred to as inter-wavelength spacing). The latter is strictly
confined to a per-port label space, whereas the former could be
defined as a local or a global (per node) label space. Such an OCh
label space is applicable to both OTN Optical Channel layer and pre-
OTN Optical Channel layer.
Optical Channel label encoding (and distribution) rules are defined
in [RFC3471]. They MUST be used for the Upstream Label, the
Suggested Label, and the Generalized Label.
5. Examples
The following examples are given in order to illustrate the
processing described in the previous sections of this document.
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
directly transported in an OTU1 (OTU2 or OTU3), the upstream node
requests results simply in an ODU1 (ODU2 or ODU3) signal request.
In such conditions, the downstream node has to return a unique
label because the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Because a single ODUk signal
is requested (Signal Type = 1, 2 or 3), the downstream node has to
return a single ODUk label, which can be, for instance, one of the
following when the Signal Type = 1:
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream node
requests results simply in an ODU1 signal request.
In such conditions, the downstream node has to return a unique
label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Because a single ODU1 multiplexed signal is requested (Signal Type
= 1 and NMC = 1), the downstream node has to return a single ODU1
label, which can take, for instance, one of the following values:
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
- t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
- t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in an ODU2 signal request.
In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2,
and NMC = 4), the downstream node has to return four ODU labels
which can take for instance the following values:
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3)
- t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
- t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3)
- t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
4. When a single OCh signal of 40 Gbps is requested (Signal Type =
8), the downstream node must return a single wavelength label as
specified in [RFC3471].
5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT)
value > 1), an explicit list of labels is returned to the
requestor node.
When the downstream node receives a request for a 4 x ODU1 signal
(Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it
returns an ordered list of four labels to the upstream node: the
first ODU1 label corresponds to the first signal of the LSP, the
second ODU1 label corresponds to the second signal of the LSP,
etc. For instance, the corresponding labels can take the
following values:
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3)
- Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
- Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3)
- Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
6. RSVP-TE Signaling Protocol Extensions
This section specifies the [RFC3473] protocol extensions needed to
accommodate G.709 traffic parameters.
The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC
and FLOWSPEC objects. The same format is used both for SENDER_TSPEC
object and FLOWSPEC objects. The content of the objects is defined
above in Section 3.2. The objects have the following class and type
for G.709:
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5
- G.709 FLOWSPEC Object: Class = 9, C-Type = 5
There is no Adspec associated with the G.709 SENDER_TSPEC. Either
the Adspec is omitted or an Int-serv Adspec with the Default General
Characterization Parameters and Guaranteed Service fragment is used,
see [RFC2210].
For a particular sender in a session, the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the contents
of the SENDER_TSPEC object received in the corresponding Path
message. If the objects do not match, a ResvErr message with a
"Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
Intermediate and egress nodes MUST verify that the node itself, and
the interfaces on which the LSP will be established, can support the
requested Signal Type, NMC, and NVC values (as defined in Section
3.2). If the requested value(s) cannot be supported, the receiver
node MUST generate a PathErr message with a "Traffic Control
Error/Service unsupported" indication (see [RFC2205]).
In addition, if the MT field is received with a zero value, the node
MUST generate a PathErr message with a "Traffic Control Error/Bad
Tspec value" indication (see [RFC2205]).
7. Security Considerations
This document introduces no new security considerations to [RFC3473].
8. IANA Considerations
Two values have been defined by IANA for this document:
Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see
Section 6.
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see
Section 6.
IANA will also track the code-point spaces extended and/or updated by
this document. For this purpose, the following new registry entries
have been added in the newly requested registry entry:
http://www.iana.org/assignments/gmpls-sig-parameters
- LSP Encoding Type:
Name: LSP Encoding Type
Format: 8-bit number
Values:
[1..11] defined in [RFC3471]
12 defined in Section 3.1.1
13 defined in Section 3.1.1
Allocation Policy:
[0..239] Assigned by IANA via IETF Standards Track RFC
Action.
[240..255] Assigned temporarily for Experimental Usage.
These will not be registered with IANA
- Switching Type:
Name: Switching Type
Format: 8-bit number
Values: defined in [RFC3471]
Allocation Policy:
[0..255] Assigned by IANA via IETF Standards Track RFC
Action.
- Generalized PID (G-PID):
Name: G-PID
Format: 16-bit number
Values:
[0..31] defined in [RFC3471]
[32..35] defined in [RFC3471] and updated by Section
3.1.3
[36..46] defined in [RFC3471]
[47..58] defined in Section 3.1.3
Allocation Policy:
[0..31743] Assigned by IANA via IETF Standards Track RFC
Action.
[31744..32767] Assigned temporarily for Experimental Usage
[32768..65535] Not assigned. Before any assignments can be
made in this range, there MUST be a Standards
Track RFC that specifies IANA Considerations
that covers the range being assigned.
Note: per [RFC3471], Section 3.1.1, standard Ethertype values are
used as G-PIDs for packet and Ethernet LSPs.
9. Acknowledgements
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot,
Massimo Canali, Germano Gasparini, and Fong Liaw for their
constructive comments and inputs as well as James Fu, Siva
Sankaranarayanan, and Yangguang Xu for their useful feedback. Many
thanks to Adrian Farrel for having thoroughly reviewed this document.
This document incorporates (upon agreement) material and ideas from a
work in progress, "Common Label and Label Request Specification for
Automatic Switched Transport Network", by Zhi Lin.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 3946, October
2004.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, September 2005.
10.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
For information on the availability of the following documents,
please see http://www.itu.int
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation (and Amendment 1), February
2001 (October 2001).
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network
Hierarchy Equipment Functional Blocks," G.798
Recommendation, October 2001.
11. Contributors
Alberto Bellato (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
EMail: alberto.bellato@alcatel.it
Sudheer Dharanikota (Consult)
EMail: sudheer@ieee.org
Michele Fontana (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
EMail: michele.fontana@alcatel.it
Nasir Ghani (Sorrento Networks)
9990 Mesa Rim Road,
San Diego, CA 92121, USA
EMail: nghani@sorrentonet.com
Gert Grammel (Alcatel)
Lorenzstrasse, 10,
70435 Stuttgart, Germany
EMail: gert.grammel@alcatel.de
Dan Guo (Turin Networks)
1415 N. McDowell Blvd,
Petaluma, CA 94954, USA
EMail: dguo@turinnetworks.com
Juergen Heiles (Siemens)
Hofmannstr. 51,
D-81379 Munich, Germany
EMail: juergen.heiles@siemens.com
Jim Jones (Alcatel)
3400 W. Plano Parkway,
Plano, TX 75075, USA
EMail: jim.d.jones@alcatel.com
Zhi-Wei Lin (Lucent)
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
EMail: zwlin@lucent.com
Eric Mannie (Consult)
EMail: eric_mannie@hotmail.com
Maarten Vissers (Alcatel)
Lorenzstrasse, 10,
70435 Stuttgart, Germany
EMail: maarten.vissers@alcalel.de
Yong Xue (WorldCom)
22001 Loudoun County Parkway,
Ashburn, VA 20147, USA
EMail: yong.xue@wcom.com
Appendix A. Abbreviations
BSNT Bit Stream without Octet Timing
BSOT Bit Stream with Octet Timing
CBR Constant Bit Rate
ESCON Enterprise Systems Connection
FC Fiber Channel
FEC Forward Error Correction
FICON Fiber Connection
FSC Fiber Switch Capable
GCC General Communication Channel
GFP Generic Framing Procedure
LSC Lambda Switch Capable
LSP Label Switched Path
MS Multiplex Section
naOH non-associated Overhead
NMC Number of Multiplexed Components
NVC Number of Virtual Components
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODTUG Optical Date Tributary Unit Group
ODU Optical Channel Data Unit
OH Overhead
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical Transport Hierarchy
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTU Optical Channel Transport Unit
OTUkV Functionally Standardized OTUk
PPP Point to Point Protocol
PSC Packet Switch Capable
RES Reserved
RS Regenerator Section
TTI Trail Trace Identifier
TDM Time Division Multiplex
Appendix B. G.709 Indexes
- Index k: The index "k" is used to represent a supported bit rate
and the different versions of OPUk, ODUk and OTUk. k=1 represents an
approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit
rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k =
4 an approximate bit rate of 160 Gbit/s (under definition). The
exact bit-rate values are in kbits/s:
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
- Index m: The index "m" is used to represent the bit rate or set of
bit rates supported on the interface. This is a one or more digit
"k", where each "k" represents a particular bit rate. The valid
values for m are (1, 2, 3, 12, 23, 123).
- Index n: The index "n" is used to represent the order of the OTM,