Internet DRAFT - draft-gasparini-ccamp-gmpls-g709-ospf-isis
draft-gasparini-ccamp-gmpls-g709-ospf-isis
CCAMP Working Group Germano Gasparini
Category: Internet Draft Gert Grammel
Expiration Date: December 2002 Dimitri Papadimitriou
- Alcatel
June 2002
Traffic Engineering Extensions to OSPF and ISIS
for GMPLS Control of G.709 Optical Transport Networks
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Abstract
This document introduces the traffic engineering extensions required
in existing IGP protocols to support sub-sequent signalling for
Label Switched Path (LSP) when using Generalized MPLS signalling as
defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical Transport
Networks (see [GMPLS-G709]). In particular, using [GMPLS-RTG] as
guideline, it specifies the GMPLS routing extensions to OSPF and IS-
IS protocols for G.709 Optical Transport Networks (OTN).
Based on the Traffic Engineering (TE) extensions defined in [OSPF-
TE] and [ISIS-TE], the proposed approach supports link bundling as
D.Papadimitriou et al. - Expires December 2002 1
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
defined in [MPLS-BDL] and defines several new sub-TLVs for Optical
Transport Network (OTN) control by extending those proposed in
[GMPLS-OSPF] and [GMPLS-ISIS]. The proposed encoding does not
preclude any further integration in these documents that the current
one intends to complement.
1. Introduction
The approach proposed in this document is based on Traffic
Engineering (TE) extensions as defined in [OSPF-TE] and [ISIS-TE]
which have been extended for GMPLS in [GMPLS-OSPF] and [GMPLS-ISIS].
The current proposal also uses the notion Link Bundling and TE Link
as defined in [MPLS-BDL]. A set of links between two adjacent GMPLS
nodes (or simply nodes) is defined as a TE-link, identified by a TE
link ID. GMPLS currently integrates the TE-link notion by detailing
among others that several links having the same Traffic Engineering
(TE) capabilities (i.e. same TE metric, same set of Resource Class
and same Switching capability) can be advertised as a single TE-
link. Such TE-links are referred to as link bundles whose individual
data bearing link (or simply links) are referred to as component
links; There is no longer a one-to-one association between a regular
routing adjacency and a TE-link.
In order to enable distributed G.709 OTN control, the IGP routing
protocol has to enable the exchange of two different sets (or types)
of information. First, a set that describes the link capabilities of
a GMPLS G.709 OTN node (or simply a node in this context),
independently of their usage. Second, a set that describes the OTN
resources (more precisely the digital timeslots or the optical
channels) that are in use at each TE link.
The first set can be defined as being driven by less frequent
updates (since TE Link capabilities changes are not expected to be
frequent) while the second would follow update interval values as
than the one used for any other non-technology dependent TE Link
attribute. We consider here that when this frequency is very low the
corresponding TE-link capability is static; by opposition, other are
referred to as dynamic. Details concerning update frequency usage
and related concepts are out of the scope of the current document.
Moreover, the G.709 Optical Transport Hierarchy (OTH) is composed by
a digital and an optical part (see [ITUT-G709]). The first one
includes the Digital Path Layer (i.e. the ODUk layers) while the
second one includes the Optical Channel Layer (i.e. the OCh layer).
Consequently we can define for of each of these hierarchies a
separated set of specific TLV. We refer to the first set as LD (Link
Digital) and to the second as LO (Link Optical).
Consequently, two specific sub-sets of information must be flooded
by an extended link state routing protocol to enable Traffic-
Engineering of the G.709 LSPs (ODUk and OCh LSPs) in OTN. First, a
set of information describing the TE Link capabilities (i.e. the
D.Papadimitriou et al. û Expires December 2002 2
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities) independently of
their usage must be defined. Then a set of information describing
the resources utilization (also referred to as ODUk or OCh component
allocation) used at each TE Link and expressed in terms of number
unallocated components.
In this way, one can reduce the amount of more static information
(since changes are less frequent when considering TE Link
capabilities) flooded through the routing protocol. This, while
keeping the more dynamic information (changes are more frequent when
considering TE Link component allocation for instance) confined to
the layer to which this information is relevant.
Routing information is exchanged in OSPF by Link State
Advertisements (LSAs) grouped in OSPF PDUs, and in IS-IS by Link
State PDUs (LSPs). When using OSPF, GMPLS TE links can be advertised
using Opaque LSAs (Link State Advertisements) of Type 10 (see [RFC-
2370]). This Traffic Engineering (TE) LSA with area flooding scope
is defined in [OSPF-TE] and has one top-level Type/Length/Value
(TLV) triplet and one or more nested sub-TLVs for extensibility.
Per [OSPF-TE], the following top-level TLVs are defined (1) Router
Address TLV (referred to as the Node TLV) and (2) TE Link TLV. When
using IS-IS, GMPLS TE links are advertised using LS PDUs. TE
Attributes TLVs are defined as sub-TLV for the Extended IS
Reachability TLV (TLV 22) (see [ISIS-TE] and [GMPLS-ISIS]).
Therefore, in this memo, we propose to extend the current sub-TLV
set of both the TE Link TLV (in OSPF) and the Extended IS
Reachability TLV (in ISIS). For each of these sets, the following
sub-TLVs are defined:
1. G.709 TE Link capabilities:
- LD-MC TLV : TE Link ODUk Multiplexing Capability TLV
- LD-CC TLV : TE Link ODUk virtual Concatenation Capability TLV
2. G.709 TE Link component allocation:
- LD-CA TLV : TE Link ODUk Component Allocation TLV
- LO-CA TLV : TE Link OCh Component Allocation TLV
Note: the proposed sub-TLVs can also complement the Interface
Switching Capability Descriptor sub-TLV of the TE Link TLV and
Extended IS Reachability TLV (see [GMPLS-OSPF] and [GMPLS-ISIS],
respectively) when the Switching Capability field value refers to
(G.709 ODU) TDM.
In addition, it results from the TE Link definition (see [MPLS-BDL])
that each of its component link should support the same multiplexing
and (virtual) concatenation capabilities. The corresponding TLVs
(LD-MC and LD-CC) are specified once, and apply to each component
link. No per component information or identification is required for
these TLVs.
D.Papadimitriou et al. û Expires December 2002 3
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
2. TE-Link Capabilities
TE-Link capabilities are (only) defined at the digital path layer
(i.e. the ODUk layers); the corresponding TE Link capability TLVs
includes:
- LD-MC TLV : TE Link ODUk Multiplexing Capability TLV
- LD-CC TLV : TE Link ODUk virtual Concatenation Capability TLV
2.1 TE Link ODUk Multiplexing Capability TLV (LD-MC TLV)
The TE Link ODUk Multiplexing Capability TLV (LD-MC TLV) describes
the ODUk multiplexing structure available on a given link. This TLV
indicates the signals that can be potentially allocated in an ODUk
multiplex.
As described in [ITUT-G709], in addition to the support of ODUk
mapping into OTUk (k = 1, 2, 3), the current version of the G.709
recommendation supports ODUk multiplexing. It refers to the
multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, 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) which is mapped into an
OPUk. The resulting OPUk is then mapped into an ODUk and the ODUk is
finally mapped into an OTUk. Subsequently, the OTUk is mapped into
an OCh/OChr, which is then modulated onto an OCC/OCCr.
In IS-IS, the LD-MC TLV is defined as a sub-TLV of the Extended IS
Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of
the Link TLV whose type is TBD. The length of this TLV is four
octets. It includes a Multiplexing Capability Flag (MC-Flag) coded
in one octet and defined as a vector of bit flags.
OSPF TE Link ODUk Multiplexing Capability TLV (LD-MC TLV) coding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MC-Flag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS TE Link ODUk Multiplexing Capability TLV coding (Sub-TLV Type
TBD and Length = 4):
D.Papadimitriou et al. û Expires December 2002 4
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MC-Flag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following values are currently defined for the MC-Flag:
- Flag 1 (Bit 1): ODU1 multiplexing into ODU2
- Flag 2 (Bit 2): ODU1 multiplexing into ODU3
- Flag 3 (Bit 3): reserved
- Flag 4 (Bit 4): ODU2 multiplexing into ODU3
- Flag 5 (Bit 5) to 8 (Bit 8): reserved
A bit value of 1 indicates that the multiplexing capability is
supported while a bit value of 0 indicates that the multiplexing
capability is not supported. For instance, the support of ODU1 and
ODU2 into ODU3 multiplexing is defined by setting the Flag 1 and the
Flag 4 to one.
Reserved Flags must be set to zero. When Flags 1 to 8 are set to
zero (in addition to the reserved field), ODUk multiplexing is not
supported on the TE link: the corresponding ODUk signal(s) is not
further structured.
2.2 TE Link ODUk virtual Concatenation Capability TLV (LD-CC TLV)
ODUk virtual concatenation refers to the concatenation of two or
more identical ODUk signals as defined in [ITUT-G709]. The resulting
signal is defined as an ODUk-Xv. The ODUk-Xv signal can then
transport a non-OTN client signal. For instance, an ODU2-4v may
transport an STM-256 client signal.
The characteristic information of a virtual concatenated ODUk (ODUk-
Xv) layer network is transported via a set of X ODUk LSP, each LSP
having its own transfer delay. The egress G.709 node terminating the
ODUk-Xv LSP has to compensate this differential delay in order to
provide a contiguous payload at the output.
In IS-IS, the TE Link ODUk Concatenation Capability TLV (LD-CC TLV)
is defined as a sub-TLV of the Extended IS Reachability TLV whose
Type is TBD. In OSPF, this TLV is a sub-TLV of the TE Link TLV, with
type TBD.
OSPF TE Link ODUk virtual Concatenation Capability TLV (LD-CC TLV)
coding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (n*4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | CT | Res. | LT | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.Papadimitriou et al. û Expires December 2002 5
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | CT | Res. | LT | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS TE Link ODUk virtual Concatenation Capability TLV coding (Sub-
TLV Type TBD and Length = n*4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | CT | Res. | LT | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// . . . //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | CT | Res. | LT | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NCC | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type (8 bits):
The Signal Type field values are defined in [GMPLS-G709].
CT û Concatenation Type (4 bits):
The CT field is defined as a 4-bit vector of flags (with bit 1
defined as the low order bit) indicating the supported
concatenation type(s):
Flag 1 (Bit 1): Reserved
Flag 2 (Bit 2): Virtual Concatenation
Flag 3 (Bit 3): Reserved
Flag 4 (Bit 4): Reserved
D.Papadimitriou et al. û Expires December 2002 6
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
Reserved (4 bits):
The Reserved field bits must be set to zero when sent and
should be ignored when received.
LT û List Type (4 bits):
The LT field indicates the type of the list; the following
values are defined (the values to which multiple lists refer
must be mutually disjoint):
0x0000 Reserved
0x0001 Inclusive list
0x0010 Exclusive list
0x0011 Inclusive range (one or more Minimum/Maximum pairs)
0x0100 Exclusive range (one or more Minimum/Maximum pairs)
Values ranging from 0x0101 to 0x1111 are reserved.
List Length (12 bits):
The List Length indicates the number of NCC elements included
within a given sub-list. Zero is an invalid value.
NCC - Number of Concatenated Components (16 bits):
The NCC field indicates the supported number X of ODU
components with respect to the Signal Type and the CT values
(here, in fact limited to virtual concatenation) that can
compose an ODUk-Xv signal on the corresponding TE Link.
When the LT field value equals 1 or 2, at least one number X1
(i.e. one NCC field) must be included in the list. When list of
numbers X1,..,Xn is included, with Xi < Xj (i < j), each Xi
indicates the number of ODUÆs supported (or not supported,
respectively) in a virtually concatenated signal.
When the LT field value equals 3 or 4, at least one pair of
numbers X1 and X2 (i.e. two NCC fields) must be included in the
list, with X1 < X2. The first one indicates the minimum number
X1 of ODUÆs and the second one the maximum number X2 of ODUÆs
supported (or not supported, respectively) in a virtually
concatenated signal.
3. TE-Link Dynamic Component Allocation
To detail the actual status of a TE-link (representing either a
single component link or a bundled link), the following Component
Allocation TLVs are defined:
- LD-CA TLV : Link ODUk Component Allocation TLV
- LO-CA TLV : Link OCh Component Allocation TLV
D.Papadimitriou et al. û Expires December 2002 7
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
3.1 Digital Path Layer
The TE Link ODUk Component Allocation TLV (LD-CA TLV) represents the
number of unallocated (free) ODU timeslots also referred to as
components, per ODUk Signal Type value (k = 1, 2, 3) on a given TE
link. Therefore, when advertised for the first time, this TLV
represents the total capacity in terms of number of ODU timeslot per
TE link i.e. the Maximum Number of ODUk components supported on this
TE link.
The LD-CA TLV is defined in IS-IS as a sub-TLV of the Extended IS
Reachability TLV whose Type is TBD. In OSPF, this TLV is a sub-TLV
of the Link TLV whose Type is TBD. The length of this sub-TLV is
max(k)*4, where max(k) is the maximum value of the k index supported
on the corresponding TE link.
OSPF Link ODUk Component Allocation TLV (LD-CA TLV) coding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = max(k)*4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated ODU TimeSlots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated ODU TimeSlots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS TE Link ODUk Component Allocation TLV coding (Sub-TLV Type TBD
and Length = max(k)*4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated ODU TimeSlots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Unallocated ODU TimeSlots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When two Number of Unallocated ODU Timeslots fields with the same
Signal Type value are advertised, the second one indicates the
number of contiguous block of unallocated ODU timeslots. Thus, when
advertised initially the corresponding value equal 1.
D.Papadimitriou et al. û Expires December 2002 8
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
Note: since currently the maximum value of the k index is 3 the
maximum length of the LD-CA TLV is 12 octets except when the blocks
of unallocated ODU timeslots are advertised.
3.2 Optical Channel (OCh) Layer
The TE Link OCh Component Allocation TLV (LO-CA TLV) represents the
number of optical channel actually allocated on a given TE link.
This TE Link can, by definition, include one (single link) or more
than one (bundled link) OTM-nr.m or OTM-n.m interface. This
allocation is expressed in terms of the Number of Unallocated
Optical Channel per bit-rate, represented here as OCh1 (2.5 Gbps),
OCh2 (10 Gbps) and OCh3 (40 Gbps), respectively. Therefore, when
advertised for the first time, the Number of Unallocated OCh1, OCh2
and OCh3 represents the Maximum Number of optical channels supported
on a given TE link at each bit rate, respectively.
The LO-CA TLV is defined in IS-IS as a sub-TLV of the Extended IS
Reachability TLV whose Type is TBD. In OSPF, this TLV is a sub-TLV
of the Link TLV whose Type is TBD. The length of this sub-TLV is
max(m)*4 octets, where max(m) is the maximum value of the m index (m
= 1, 2, 3) supported on the corresponding TE link. The Signal Type
field values are defined in [GMPLS-G709].
OSPF TE Link OCh Component Allocation TLV (LO-CA TLV) coding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = max(m)*4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |R| Number of Unallocated OCh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |R| Number of Unallocated OCh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ISIS TE Link OCh Component Allocation TLV coding (Sub-TLV Type TBD
and Length = max(m)*4 octets):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |R| Number of Unallocated OCh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |R| Number of Unallocated OCh |
D.Papadimitriou et al. û Expires December 2002 9
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The R bit indicates the functionality of the corresponding OTM-
n.m/OTM-nr.m interface(s). When R = 0, the interface signal refers
to an OTM-n.m (reduced functionality OChr) while R = 1, to an OTM-
nr.m (full functionality OCh). The value of this bit is irrelevant
in any other situation.
Therefore this encoding allows for TE links including both OTM-nr.m
and OTM-n.m interfaces. Each component link belonging to the same TE
Link can have independently from each other a reduced OR a full
functionality stack support. Thus, reduced AND full optical channels
at 2.5, 10 or 40 Gbps can compose TE links.
Since currently the maximum value of the m index is 3, the maximum
length of the LO-CA TLV is 24 octets: 2 x (3 x 4) octets.
Note: OCh Multiplexing Capability
As described in [ITUT-G709], with reduced stack functionality: up to
n (n >= 1) OCCr are multiplexed into an OCG-nr.m using wavelength
division multiplexing. The OCCr tributary slots of the OCG-nr.m can
be of different size (depending on the m value with m = 1, 2, 3).
The number of OCCr that can be multiplexed into an OCG-nr.m is
bounded by the following formula: 1 =< i + j + k =< n where i
(respectively, k and j) represents the number of OChr carrying an
OTU1 (respectively, OTU2 and OTU3). The OCG-nr.m is transported via
the OTM-nr.m.
With full stack functionality: up to n (n >= 1) OCC are multiplexed
into an OCG-n.m using wavelength division multiplexing. The OCC
tributary slots of the OCG-n.m can be of different size (depending
on the m value with m = 1, 2, 3). The number of OCC that can be
multiplexed into an OCG-n.m is bounded by the following formula: 1
=< i + j + k =< n where i (respectively, k and j) represents the
number of OCh carrying an OTU1 (respectively, OTU2 and OTU3). The
OCG-n.m is transported via the OTM-n.m.
4. Security Considerations
Routing protocol related security considerations are identical to
the on referenced in [OSPF-TE] and [ISIS-TE].
5. References
[GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol
Label Switching (GMPLS) ArchitectureÆ, Internet Draft,
Work in progress, draft-ietf-ccamp-gmpls-architecture-
02.txt, February 2002.
[GMPLS-G709] D.Papadimitriou (Editor) et al., æGeneralized MPLS
Signalling Extensions for G.709 Optical Transport
D.Papadimitriou et al. û Expires December 2002 10
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
NetworksÆ, Internet Draft, Work in progress, draft-
ietf-ccamp-gmpls-g709-01.txt, June 2002.
[GMPLS-ISIS] K.Kompella et al., æIS-IS Extensions in Support of
Generalized MPLS,Æ Internet Draft, Work in progress,
draft-ietf-isis-gmpls-extensions-12.txt, May 2002.
[GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
CR-LDP ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002.
[GMPLS-OSPF] K.Kompella et al., æOSPF Extensions in Support of
Generalized MPLS,Æ Internet Draft, Work in progress,
draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, April
2002
[GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
RSVP-TE ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002.
[GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS - Signaling
Functional DescriptionÆ, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-signaling-08.txt,
April 2002.
[GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
"GMPLS extensions for SONET and SDH control", Internet
Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-
sdh-05.txt, June 2002.
[ISIS-TE] T.Li et al.,æIS-IS Extensions for Traffic EngineeringÆ,
Internet Draft, Work in Progress, draft-ietf-isis-
traffic-04.txt, August 2001.
[ITUT-G707] ITU-T G.707 Recommendation, æNetwork node interface for
the synchronous digital hierarchy (SDH)Æ, ITU-T,
October 2000.
[ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment
1), æInterface for the Optical Transport Network
(OTN)Æ, ITU-T, October 2001.
[MPLS-BDL] K.Kompella et al., æLink Bundling in MPLS Traffic
Engineering,Æ Internet Draft, draft-ietf-mpls-bundle-
03.txt, May 2002.
[OSPF-TE] D.Katz, D.Yeung et K.Kompella, "Traffic Engineering
Extensions to OSPF", draft-katz-yeung-ospf-traffic-
06.txt, Internet Draft, Work in progress, October 2001.
[RFC-2370] R. Coltun, RFC 2370, Standard Track, "The OSPF Opaque
LSA Option", IETF, July 1998.
D.Papadimitriou et al. û Expires December 2002 11
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
6. Acknowledgments
The authors would like to thank Alberto Bellato, Michele Fontana,
and Jim Jones for their constructive comments and inputs leading to
the current version of this document.
7. Author's Addresses
Germano Gasparini (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7670
Email: germano.gasparini@netit.alcatel.it
Gert Grammel (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
D.Papadimitriou et al. û Expires December 2002 12
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
Appendix 1 û Abbreviations
1R Re-amplification
2R Re-amplification and Re-shaping
3R Re-amplification, Re-shaping and Re-timing
AI Adapted information
AIS Alarm Indication Signal
APS Automatic Protection Switching
BDI Backward Defect Indication
BEI Backward Error Indication
BI Backward Indication
BIP Bit Interleaved Parity
CBR Constant Bit Rate
CI Characteristic information
CM Connection Monitoring
EDC Error Detection Code
EXP Experimental
ExTI Expected Trace Identifier
FAS Frame Alignment Signal
FDI Forward Defect Indication
FEC Forward Error Correction
GCC General Communication Channel
IaDI Intra-Domain Interface
IAE Incoming Alignment Error
IrDI Inter-Domain Interface
MFAS MultiFrame Alignment Signal
MS Maintenance Signal
naOH non-associated Overhead
NNI Network-to-Network interface
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCI Open Connection Indication
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
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
PCC Protection Communication Channel
PLD Payload
PM Path Monitoring
PMI Payload Missing Indication
PRBS Pseudo Random Binary Sequence
PSI Payload Structure Identifier
D.Papadimitriou et al. û Expires December 2002 13
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
PT Payload Type
RES Reserved
RS Reed-Solomon
SM Section Monitoring
TC Tandem Connection
TCM Tandem Connection Monitoring
UNI User-to-Network Interface
Appendix 2 û 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,
OTS, OMS, OPS, OCG and OMU. This index represents the maximum
number of wavelengths that can be supported at the lowest bit rate
supported on the wavelength. It is possible that a reduced number
of higher bit rate wavelengths are supported. The case n=0
represents a single channel without a specific wavelength assigned
to the channel.
- Index r: The index "r", if present, is used to indicate a reduced
functionality OTM, OCG, OCC and OCh (non-associated overhead is
not supported). Note that for n=0 the index r is not required as
it implies always reduced functionality.
D.Papadimitriou et al. û Expires December 2002 14
draft-gasparini-ccamp-gmpls-g709-ospf-isis-03.txt June 2002
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."
D.Papadimitriou et al. û Expires December 2002 15
