idnits 2.17.1 draft-oki-ipo-optlink-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8099 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GMPLS-ROUTING' is defined on line 256, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-01 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eiji Oki 3 Internet Draft NTT 4 Expiration Date: August 2002 Nobuaki Matsuura 5 NTT 6 Wataru Imajuku 7 NTT 8 Kohei Shiomoto 9 NTT 10 Naoaki Yamanaka 11 NTT 12 February 2002 14 Requirements of optical link-state information for traffic engineering 15 draft-oki-ipo-optlink-req-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 In a limited/non-wavelength-convertible (LNWC) optical network, a 44 wavelength is restricted to be converted into another wavelength on 45 an optical path due to the limitation of wavelength converters at an 46 optical cross-connect. This document describes requirements of 47 optical link-state information for traffic engineering to solve the 48 routing and wavelength assignment (RWA) problem in LNWC network. 49 Additional link-information extensions for LNWC network are 51 draft-oki-ipo-optlink-req-00.txt February 2002 53 presented. By using the information, extensions of OSPF and RSVP-TE 54 are proposed. 56 1. Introduction 58 Traffic engineering (TE) in optical networks is useful to efficiently 59 utilize network resources, which are fibers, wavelengths, and node 60 capacities, etc. In GMPLS networks, a source node finds an 61 appropriate route and wavelength based on collected optical link- 62 state information with a routing protocol as such as Open Shortest 63 Path Finding (OSPF) [GMPLS-OSPF], and set up an optical path by using 64 a signaling protocol such as RSVP-TE [GMPLS-SIG][GMPLS-RSVP]. 66 A wavelength-division multiplexing (WDM) optical network are mainly 67 categorized into two types in terms of wavelength conversion 68 capability. One is a limited/non-wavelength-convertible (LNWC) 69 optical network. The other is a wavelength-convertible (WC) optical 70 network. 72 In LNWC network, a wavelength is limitedly or not converted into 73 another wavelength on an optical path. Because of the limitation of 74 wavelength converters at optical cross-connects (OXCs), an optical 75 path must use the same or limited wavelength(s) through an optical 76 path. When an optical path is set up, the routing and wavelength 77 assignment (RWA) problem has to be solved. On the other hand, in WC 78 network, any wavelength can be converted into any wavelength at OXC 79 on an optical path. 81 This draft describe requirements of optical link-state information 82 for traffic engineering to solve the RWA problem. Additional link- 83 information extensions for LNWC network are presented. By using the 84 information, extensions of OSPF and RSVP-TE are proposed. 86 In this draft, an optical link is used as a TE-link between neighbor 87 OXCs or between neighbor OXC and a label switch router (LSR). We 88 refer OXC or LSR to a node. Component links (or ports), each of which 89 may corresponding to a wavelength, in one or multiple fiber(s) are 90 bundled into a TE-link [LINK-BUNDLE], where every wavelength 91 information is aggregated. Figure 1 shows an example of an optical 92 network model. OXC is used to refer to all categories of optical 93 cross-connects, irrespective of the internal switching fabric. The 94 left side of OXC 1 has a 3R. The right side of OXC 1, both sides of 95 OXC2, and LSR 2 have WDM functions. o-link 1 and o-link 2 are defined 96 as a single TE-link that budles multiple componet links. 98 LSR 1 ----- OXC 1 ====== OXC 2 ====== LSR 2 99 o-link 1 o-link 2 101 draft-oki-ipo-optlink-req-00.txt February 2002 103 Figure 1: Example of optical network model 105 2. Requirements of optical link-state information in LNWC network 107 Since wavelength is limitedly or not converted into another 108 wavelength in LNWC network, information which wavelength is reserved 109 in a TE-link is necessary for traffic engineering. Note that 110 wavelengths in more than one fiber are not considered to be bundled 111 into a TE-link in LNWC network, because the same wavelengths in more 112 than one fiber should be differently handled for a purpose of traffic 113 engineering. Wavelength status to indicate which wavelength is 114 reserved/unreserved in a TE-link. The wavelength status is used to 115 solve the RWA problem. 117 However, opaque LSA sub-TLVs, which is defined in [OSPF-TE][GMPLS- 118 OSPF], for a bundled TE-link between neighbor nodes do not express 119 the wavelength status and not advertise it. Therefore, link- 120 information extensions need to be added to achieve traffic 121 engineering in LNWC network. 123 3. Label Definition for Corresponding Wavelength Value 125 Wavelength value (e.g., 1550 nm) should be globally considered in 126 LNWC network. For a purpose of the advertisement of wavelength status 127 in a TE-link and signalling to set up an optical path, each 128 wavelength value should be globally defined as a label in the LNWC 129 network. 131 There are several possible ways to assign a label to the 132 corresponding wavelength value. One way to assign a label is to 133 express the wavelength value itself (unit: nm) with 4 octets field in 134 the IEEE floating point format. Another way is to use three types of 135 integer parameters, which are wavebands (C, L, S), ITU grid spacing 136 (e.g., 25, 50, and 100 GHz), and deviation from the reference center 137 frequency of the corresponding waveband. 139 4. OSPF extensions 141 To indicate the wavelength status in a TE-link between neighbor nodes, 142 there are two possible ways as follows. 144 4. 1 Explicit label scheme 146 Labels corresponding wavelengths with indication bits to express the 147 wavelength status in a TE-link between neighbor nodes are explicitly 148 advertised. If the status of a wavelength is changed, the 149 corresponding label with the indication bit are updated and 150 advertised. In the explicit label scheme, the information amount to 152 draft-oki-ipo-optlink-req-00.txt February 2002 154 advertise the wavelength status may be increased when the number of 155 used labels are large. 157 4. 2 Bitmap scheme 159 A set of labels that are used in LNWC network is advertised. 160 Indication bits to express the wavelength status as a label set are 161 advertised by using a bitmap format. In the bitmap format, the 162 indication bits appear in an increasing order with label values. If a 163 value of the indication bit is 1, the label is reserved. If a value 164 of the indication bit is 0, the label is reserved. Every time the 165 status for each wavelength is changed, label values themselves do not 166 need to be advertised. Instead of that, only the indication bits with 167 the bitmap format are advertised. When a set of the labels that are 168 used in the LNWC network is updated, the updated set of the labels is 169 advertised. 171 5. RSVP-TE extensions 173 5. 1 AND scheme 175 When a path message attempts to set up an optical path at each 176 source/transit OXC, it carries a set of unreserved labels that are 177 unreserved through all the TE-links from the source OXC to the 178 transit OXC. The label set is called an AND label set. If there is 179 at least a reserved label in a TE-link from the source OXC to the 180 transit OXC, the label is excluded in the transit node from the AND 181 set. If there is no label in the AND set, the transit OXC should 182 perform a wavelength conversion. Otherwise, the request of the 183 optical path set-up is rejected. 185 There are two possible ways to carry an AND label set of unreserved 186 labels, the explicit label scheme and the bitmap scheme as described 187 in Section 4. The explicit label scheme is considered in [GMPLS- 188 RSVP] as 'label set'. 190 5. 2 ALL scheme 192 When a path message attempts to set up an optical path at each 193 source/transit node, it carries a set of unreserved labels for all 194 TE-links on an optical path. The label set is called an ALL label 195 set. A destination node receives the ALL label set and decides which 196 labels should be used on the optical path. In the ALL scheme, the 197 destination node has several options on which node should use a 198 wavelength-conversion function if it is needed. 200 There are two possible ways to carry a set of unreserved label, the 201 explicit label scheme and the bitmap scheme in the same way as the 203 draft-oki-ipo-optlink-req-00.txt February 2002 205 AND scheme. Note that the ALL scheme carries each label set for all 206 the TE-links on the optical path, while the AND scheme carries a 207 label set for each optical path. 209 6. Requirements of optical link-state information in WC Network 211 Since any wavelength can be converted into any wavelength at OXC, 212 information which wavelength is reserved in a TE-link is not 213 necessary. The number of wavelengths (NW) and the number of 214 unreserved wavelengths (NUW) in a TE-link are used for traffic 215 engineering. For example, a least-loaded path finding algorithm is 216 employed to find an appropriate optical path. 218 The optical-link information in a TE-link between two neighbor nodes 219 is advertised. Therefore, multiple ports of OXC, each of which is 220 corresponding to each wavelength may be combined into a TE-link. In 221 OSPF extensions, opaque LSA sub-TLVs includes maximum reservable 222 bandwidth and unreserved bandwidth, which sub-TLV types are 7 and 8, 223 respectively. NW and NUW are expressed by using maximum reservable 224 bandwidth and unreserved bandwidth for a bundled TE-link between 225 neighbor nodes in the following. .nf NW = maximum reservable 226 bandwidth for a bundled TE-link 227 = sum of maximum reservable bandwidth of all component links 228 and 229 NUW = unreservable bandwidth for a bundled TE-link 230 = sum of unreservable bandwidth of all component links. 231 Note that NW is not the number of wavelength in a fiber, but is the 232 number of ports, in other words, wavelengths, of OXC in a TE-link. 234 However, the units of the maximum reservable bandwidth and 235 unreservable bandwidth are defined as byte per second [GMPLS-OSPF]. 236 Since the values of NUW and NW are independent of byte per second, 237 the modification of the units or a sub-TLV definition is needed. 239 7. References 241 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 242 OSPF", draft-katz-yeung-ospf-traffic-06.txt (work in progress) 244 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 245 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 246 gmpls-extensions-00.txt (work in progress) 248 [GMPLS-SIG] "Generalized MPLS - Signaling Functional Description", 249 draft-ietf-mpls-generalized-signaling-04.txt (work in progress) 251 [GMPLS-RSVP] "Generalized MPLS Signaling - RSVP-TE Extensions", 252 draft-ietf-mpls-generalized-rsvp-te-07.txt (work in progress) 254 draft-oki-ipo-optlink-req-00.txt February 2002 256 [GMPLS-ROUTING] "Routing Extensions in Support of Generalized MPLS", 257 draft-ietf-ccamp-gmpls-routing-02.txt (work in progress) 259 [LINK-BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 260 in MPLS Traffic Engineering", draft-ietf-mpls-bundle-01.txt (work in 261 progress) 263 8. Authors' Addresses 265 Eiji Oki 266 NTT Corporation 267 3-9-11 Midori-cho, 268 Musashino-shi, Tokyo 180-8585, Japan 269 Email: oki.eiji@lab.ntt.co.jp 271 Nobuaki Matsuura 272 NTT Corporation 273 3-9-11 Midori-cho, 274 Musashino-shi, Tokyo 180-8585, Japan 275 Email: matsuura.nobuaki@lab.ntt.co.jp 277 Wataru Imajuku 278 NTT Corporation 279 1-1 Hikari-no-oka, 280 Yokosuka, Kanagawa, 239-0847 Japan 281 Email: imajyuku@exa.onlab.ntt.co.jp 283 Kohei Shiomoto 284 NTT Corporation 285 3-9-11 Midori-cho, 286 Musashino-shi, Tokyo 180-8585, Japan 287 Email: shiomoto.kohei@lab.ntt.co.jp 289 Naoaki Yamanaka 290 NTT Corporation 291 3-9-11 Midori-cho, 292 Musashino-shi, Tokyo 180-8585, Japan 293 Email: yamanaka.naoaki@lab.ntt.co.jp