CCAMP Working Group Germano Gasparini Category: Internet Draft Gert Grammel Expiration Date: May 2003 Dimitri Papadimitriou Alcatel November 2002 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of G.709 Networks draft-gasparini-ccamp-gmpls-g709-ospf-00.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]. (*) Previously draft-gasparini-ccamp-gmpls-g709-ospfùisis-03.txt 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 (GMPLS) signalling as defined in [GMPLS-SIG] and [GMPLS-G709] for G.709 Optical Transport Networks. 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). D.Papadimitriou et al. - Expires May 2003 1 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 Based on the Traffic Engineering (TE) extensions defined in [OSPF- TE], the proposed approach is aligned with link bundling as defined in [MPLS-BDL] and extends the TE link sub-TLVs proposed in [GMPLS- OSPF] by proposing several new sub-TLVs for G.709 networks. The proposed extensions do not preclude any further integration with the one it intends to complement. 1. Introduction The approach proposed in this document is based on Traffic Engineering (TE) extensions as defined in [OSPF-TE] which have been extended for GMPLS purposes in [GMPLS-OSPF]. The current proposal also uses the notion Link Bundling and TE link as defined in [MPLS- BDL]. In this context, a set of links between two adjacent GMPLS nodes (or simply nodes) is defined as a TE link. GMPLS currently integrates the TE link notion by specifying 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 (or ports). Moreover, 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 transport network control, the link state routing protocol has to enable the exchange of two different sets (or types) of information. First, a set that describes the link capabilities belonging to a GMPLS G.709 LSR (or simply a G.709 node in the present context) and this, independently of their usage. Second, a set that describes the resources (more precisely the timeslots or the optical channels) that are in use at each of its TE links. 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 one would follow update interval values as than the one used for any other non-technology dependent TE link attribute (see [GMPLS-OSPF]). Therefore, one considers that when this frequency is very low the corresponding TE link capability is (quasi-)static; by opposition, others are referred to as dynamic. Details concerning update frequency usage and related concepts are out of the scope of this memo. Moreover, the G.709 Optical Transport Hierarchy (OTH) is composed by a digital and an optical part (see [ITUT-G709]). The former one includes the Digital Path Layer (a.k.a. ODUk) while the latter one includes the Optical Channel Layer (a.k.a. OCh). Consequently we can define for of each of them a dedicated set of specific TLV. In brief, this memo defines two additional sub-sets of information. Their flooding enables the Traffic Engineering of the G.709 LSPs (i.e. the ODUk and OCh LSPs). The first set describes the TE link D.Papadimitriou et al. û Expires April 2003 2 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 capabilities (i.e. the OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities) and this, independently of their usage. The second set describes the resources utilization (referred to as ODUk or OCh components) used at each TE link and expressed in terms of number of unallocated components per TE link. 2. OSPF Routing Extensions In 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. Also, nodes shall originate TE LSAs whenever their content change, and whenever required by OSPF (for example, originate an LSA refresh when the LSA age field reaches the LSRefreshTime). However, this does not mean that every LSA contents change must be flooded immediately. As specified in [RFC-2328], the origination of TE LSAs SHOULD be rate-limited to at most one every MinLSInterval. Upon receipt of a changed TE LSA or Network LSA (since these are used in TE calculations), the node should update its TE link state database without necessarily performing any (Constraint-)SPF or other path computation. Per [OSPF-TE], two top-level TLVs are defined (1) the Router Address TLV (referred to as the Node TLV) and (2) the TE link TLV. This memo extends the current sub-TLV set of the TE link TLV by defining: 1. G.709 TE link capabilities: - ODUk Multiplexing Capability sub-TLV - ODUk virtual Concatenation Capability sub-TLV 2. G.709 TE link component allocation: - ODUk Component Allocation sub-TLV - OCh Component Allocation sub-TLV Also, the proposed sub-TLVs can complement the Interface Switching Capability Descriptor sub-TLV of the TE link TLV (see [GMPLS-OSPF]) when the Switching Capability field value refers to (G.709 ODU) TDM. Using the above classification, one can reduce the amount of more static information flooded since changes are much less frequent when considering TE link capabilities (see [OSPF-DNA] for instance). This, while keeping the more dynamic information (changes are more frequent when considering TE link component allocation for instance) confined to the region to which this information is relevant. 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 sub-TLVs 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 April 2003 3 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 3. TE Link Capabilities Additional TE link capabilities are (only) defined at the digital path layer (i.e. the ODUk layers) and include the ODUk Multiplexing Capability sub-TLV and ODUk virtual Concatenation Capability sub- TLV. 3.1 TE Link ODUk Multiplexing Capability sub-TLV The TE link ODUk Multiplexing Capability sub-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. The ODUk Multiplexing Capability sub-TLV is a sub-TLV of the Link TLV whose type is TBD. The length of this TLV is four octets. It includes a 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MC-Flag (8 bits): The Multiplexing Capability Flag (MC-Flag) field is coded in one octet and defined as a vector of bit flags. 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 D.Papadimitriou et al. û Expires April 2003 4 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 - 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. Reserved (24 bits) This field SHOULD be set to zero when sent and MUST be ignored when received. 3.2 TE Link ODUk virtual Concatenation Capability sub-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. The TE link ODUk (virtual) Concatenation Capability sub-TLV whose Type is TBD has the following encoding: 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 = M*(2*N + 4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | CT | Res. | LT | List Length (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NCC | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NCC | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | CT | Res. | LT | List Length (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NCC | . . . | D.Papadimitriou et al. û Expires April 2003 5 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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). A flag set to 1 indicates the support of the corresponding concatenation type: Flag 1 (Bit 1): Reserved Flag 2 (Bit 2): Virtual Concatenation Flag 3 (Bit 3): Reserved Flag 4 (Bit 4): Reserved Reserved flags MUST be set to zero when sent and ignored when received. 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 field indicates the number N of NCC fields (of 16 bits) comprised in a given list including the zero padding field. Zero is an invalid value (or equivalently, the number N MUST be greater than 0 and the minimum sub-TLV length is of 8 octets). 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 D.Papadimitriou et al. û Expires April 2003 6 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 (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. When this sub-TLV includes several lists (defined with the same Type), the NCC values that each list contain, MUST be mutually consistent. A NCC value equal to zero refers to a zero padding field. Note that the maximum value of X is currently 16 (ODU1-16v) therefore limiting the size of this sub-TLV to at most 16 x (4 + 4) octets (i.e. worst case with one NCC field per list including zero padding). 4. TE Link Component Allocation To detail the actual resource utilization status of a TE link (representing either a single component link or a bundled link), the following TE link Component Allocation sub-TLVs are defined: 4.1 ODUk TE Link Component Allocation sub-TLV The ODUk TE link Component Allocation sub-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 sub-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 ODUk Component Allocation sub-TLV whose Type is TBD has a length of max(k)*4, where max(k) is the maximum value of the k index supported on the corresponding TE link. Its encoding is defined as: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.Papadimitriou et al. û Expires April 2003 7 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 | | | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Unallocated ODU Timeslots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signal Type (8 bits): The valid Signal Type field values are defined in [GMPLS-G709]. Number of Unallocated ODU Timeslots (24 bits): This field indicates, per TE link, the number of unallocated ODUk timeslots, k being implicitly specified by the Signal Type field value. Note: since currently the maximum value of the k index is 3 the maximum length of this sub-TLV is 12 octets. 4.2 Optical Channel (OCh) Component Allocation sub-TLV The TE link OCh Component Allocation sub-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 m i.e. at 2.5 Gbps (m = 1), 10 Gbps (m = 2) and 40 Gbps (m = 3). Therefore, when advertised for the first time, the Number of Unallocated OCh represents for each supported bit rate the Maximum Number of optical channels supported on a given TE link. The OCh Component Allocation TLV sub-TLV is a sub-TLV of the Link TLV with 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. Its encoding is defined as: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid Signal Type field values are defined in [GMPLS-G709]. D.Papadimitriou et al. û Expires April 2003 8 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 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 the maximum value of the m index, as currently defined, is 3, the maximum length of this sub-TLV is 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. 5. Scalability Considerations A G.709-capable node should try to minimize the amount of routing information it floods. Each time a signal is allocated or released that information shall be flooded (not necessarily immediately) to all nodes in the routing domain. This applies particularly to the Component Allocation sub-TLVs. Removing an LSA is done in OSPF by prematurely aging the LSA. The LSA is re-flooded with an LSA age equal to MaxAge. Each node receiving an existing LSA with MaxAge removes it from its link state database. Also, the usage of OSPF implies each LSA must be refreshed periodically (when the LSA age field reaches the LSRefreshTime, see [RFC-2328]) to avoid age timeout and removal from the link state database. This periodical LSA flooding and processing applies particularly to the Capability sub-TLVs defined in this document D.Papadimitriou et al. û Expires April 2003 9 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 since their variation period is expected to be much larger than the LSRefreshTime. As specified in [RFC-2370], an Opaque LSA has a length field of 16 bits indicating the length of the LSA, including the header. Thus, the length of OSPF packets can be up to 65535 octets (including the IP header). Moreover, an OSPF packet can contain several LSAs. OSPF relies if necessary on the IP fragmentation to transmit large packets. However this is not recommended and it is suggested to split packets that are too large into several smaller packets. This is possible without any loss of functionality. It has also to be emphasized that none of the sub-TLVs defined in this document exceed 128 octets. Therefore, there is no particular issue due to the size of G.709 sub-TLV to be flooded in TE LSAs. In brief, there are no more (or less) scalability issues with the proposed sub-TLVs (and the proposed encoding together with their processing) than the ones already introduced in [OSPF-TE] and [GMPLS-OSPF]. 7. Compatibility Considerations There should be no interoperability issues with G.709 GMPLS-capable nodes that do not implement the proposed extensions, as the Opaque LSAs (and the sub-TLVs proposed in this document) will be silently ignored. The result of having such nodes that do not implement these extensions is that the G.709 specific traffic engineering topology will be missing. However, TE constraint paths can still be calculated using the [OSPF-TE] and [GMPLS-OSPF] technology independent TE link sub-TLVs. 8. Security Considerations Routing protocol related security considerations are identical to the on referenced in [OSPF-TE] and [ISIS-TE]. 9. 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- 03.txt, August 2002. [GMPLS-G709] D.Papadimitriou (Editor) et al., ôGeneralized MPLS Signalling Extensions for G.709 Optical Transport Networksö, Internet Draft, Work in progress, draft- ietf-ccamp-gmpls-g709-03.txt, November 2002. D.Papadimitriou et al. û Expires April 2003 10 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 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-07.txt, August 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-08.txt, August 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-08.txt, August 2002. [GMPLS-RTG] K.Kompella et al., ôRouting Extensions in Support of Generalized MPLS,ö Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing-05.txt, August 2002. [GMPLS-SIG] L.Berger (Editor) et al., ôGeneralized MPLS - Signaling Functional Descriptionö, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-09.txt, August 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-07.txt, October 2002. [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, Work in progress, draft- ietf-mpls-bundle-04.txt, August 2002. [OSPF-DNA] P.Pillay-Esnault et al., ôOSPF Refresh and flooding reduction in stable topologies,ö Internet Draft, Work in progress, draft-pillay-esnault-ospf-flooding-03.txt, December 2000. [OSPF-TE] D.Katz, D.Yeung and K.Kompella, ôTraffic Engineering Extensions to OSPFö, draft-katz-yeung-ospf-traffic- 09.txt, Internet Draft, Work in progress, October 2002. [RFC-2328] J.Moy, RFC 2328, ôOSPF Version 2ö, STD 54, IETF Standard Track, April 1998. D.Papadimitriou et al. û Expires April 2003 11 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 2002 [RFC-2370] R.Coltun, RFC 2370, ôThe OSPF Opaque LSA Optionö, IETF Standard Track, July 1998. 10. 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. 11. 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 April 2003 12 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 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 April 2003 13 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 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 April 2003 14 draft-gasparini-ccamp-gmpls-g709-ospf-04.txt Nov. 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 April 2003 15