idnits 2.17.1 draft-fredette-lmp-wdm-03.txt: -(236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(353): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(688): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 14 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([LMP], [OLI]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 282: '...ndependently and MUST be maintained se...' RFC 2119 keyword, line 290: '...ween the sessions, it MUST be possible...' RFC 2119 keyword, line 292: '... MUST be possible for an OXC-OXC LMP...' RFC 2119 keyword, line 357: '...rted by the node, it MUST reply to the...' RFC 2119 keyword, line 402: '...pe and Length fields. The Length MUST...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2001) is 8196 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) == Missing Reference: 'RFC2026' is mentioned on line 38, but not defined == Unused Reference: 'Bra96' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'DBC00' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'KRB00' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'KRB00a' is defined on line 995, but no explicit reference was found in the text == Unused Reference: 'SDH' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'SONET' is defined on line 1013, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'DBC00' == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. 'KRB00' -- No information found for draft-kompella-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB00a' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-02 -- Possible downref: Normative reference to a draft: ref. 'OLI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andre Fredette (PhotonEx Corp.) (Editor) 3 Internet Draft Jonathan Lang (Calient Networks) (Editor) 4 Expiration Date: May 2002 5 Osama Aboul-Magd (Nortel Networks) 6 S. Brorson (Axiowave Networks) 7 S. Dharanikota (Nayna Networks, Inc) 8 John Drake (Calient Networks) 9 David Drysdale (Data Connection) 10 W. L. Edwards (iLambda Networks) 11 Adrian Farrel (Movaz Networks) 12 R. Goyal (Axiowave Networks) 13 Hirokazu Ishimatsu (Japan Telecom) 14 Monika Jaeger (T-systems) 15 R. Krishnan (Axiowave Networks) 16 Raghu Mannam (Hitachi Telecom) 17 Eric Mannie (Ebone (GTS)) 18 Dimitri Papadimitriou (Alcatel) 19 Vasant Sahay (Nortel Networks) 20 Jagan Shantigram (PhotonEx Corp.) 21 Ed Snyder (PhotonEx Corp.) 22 George Swallow (Cisco Systems) 23 G. Tumuluri (Calient Networks) 24 Y. Xue (UUNET/WorldCom) 25 Lucy Yong (Williams Communications) 26 J. Yu (Zaffire, Inc) 28 November 2001 30 Link Management Protocol (LMP) for DWDM Optical Line Systems 32 draft-fredette-lmp-wdm-03.txt 34 Status of this Memo 36 This document is an Internet-Draft and is in full conformance with 37 all provisions of Section 10 of RFC2026 [RFC2026]. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet- Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 ABSTRACT 56 A suite of protocols is being developed in the IETF to allow 57 networks consisting of photonic switches (PXCs), optical 58 crossconnects (OXCs), routers, switches, DWDM optical line systems 59 (OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS- 60 based control plane to dynamically provision resources and to 61 provide network survivability using protection and restoration 62 techniques. As part of this protocol suite, the Link Management 63 Protocol (LMP) [LMP] is defined to "maintain control channel 64 connectivity, verify component link connectivity, and isolate link, 65 fiber, or channel failures within the network." In it's present 66 form, [LMP] focuses on peer communications (eg. OXC-to-OXC). In 67 this document we propose extensions to LMP for use with OLSs. These 68 extensions are intended to satisfy the "Optical Link Interface 69 Requirements" described in [OLI]. 71 CONTENTS 72 1. Introduction.......................................................5 73 2. LMP Extensions for Optical Line Systems............................7 74 2.1. Control Channel Management.......................................8 75 2.2. Link Verification................................................8 76 2.3. Link Summarization...............................................8 77 2.3.1. Link Group ID..................................................9 78 2.3.2. Shared Risk Link Group Identifier (SRLG):.....................10 79 2.3.3. Bit Error Rate (BER) Estimate.................................10 80 2.3.4. Optical Protection............................................11 81 2.3.5. Total Span Length:............................................11 82 2.3.6. Administrative Group (Color)..................................12 83 2.4. Fault Management................................................12 84 2.4.1. LINK GROUP CHANNEL_STATUS Object..............................13 85 2.5. Alarm Management................................................14 86 2.6. Trace Monitoring................................................15 87 2.6.1. TraceMonitor Message (MsgType = TBD)..........................15 88 2.6.1.1. TRACE Object................................................15 89 2.6.2. TraceMonitorAck Message (MsgType = TBD).......................16 90 2.6.3. TraceMonitorNack Message (MsgType = TBD)......................16 91 2.6.3.1. ERROR_CODE Class............................................17 92 2.6.4. TraceMismatch Message (MsgType = TBD).........................17 93 2.6.5. TraceMismatchAck Message (MsgType = TBD)......................17 94 2.6.6. TraceReq Message (MsgType = TBD)..............................17 95 2.6.7. TraceReport Message (MsgType = TBD)...........................18 96 2.6.8. TraceReqNak Message (MsgType = TBD)...........................18 97 2.6.9. InsertTraceReq Message (MsgType = TBD)........................18 98 2.6.10. InsertTraceAck Message (MsgType = TBD).......................18 99 2.6.11. InsertTraceNack Message (MsgType = TBD)......................19 100 3. Security Considerations...........................................19 101 4. Work Items........................................................19 102 5. References........................................................20 103 6. Author's Addresses................................................21 104 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS 105 (Section Requested by Bert and Scott) 107 SUMMARY 109 This work is motivated by two main issues. The first is the need to 110 enhance the fault detection and recovery support for photonic 111 switches (PXCs), and the second is to enhance the discovery of link 112 characteristics for optical networks in general. 114 GMPLS is being developed to allow networks consisting of photonic 115 switches (PXCs), optical crossconnects (OXCs), routers, switches and 116 optical line systems (OLS) (or DWDM systems) to use an MPLS-based 117 control plane to dynamically provision resources and to provide 118 network survivability using protection and restoration techniques. 119 As part of this protocol suite, the Link Management Protocol (LMP) 120 [LMP] is defined to "maintain control channel connectivity, verify 121 component link connectivity, and isolate link, fiber, or channel 122 failures within the network." In it's present form, [LMP] focuses 123 on peer communications (e.g., OXC-to-OXC). In this document we 124 propose extensions to LMP for use with optical line systems. These 125 extensions allow the OLS to inform attached devices, such as routers 126 or PXCs, of (1) link properties needed for routing/signalling and 127 (2) link failures that can be used to drive failure recovery 128 protocols. 130 RELATED DOCUMENTS 132 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-02.txt 133 http://www.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt 135 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 137 lmp-wdm fits in the Control part of the sub-ip work. 139 WHY IS IT TARGETED AT THIS WG 141 lmp-wdm enhances the ability of circuit switches and routers using 142 MPLS-based control protocols to dynamically discover link properties 143 and to learn about link status. The link properties can be useful 144 during signalling of paths, and the link status information is 145 essential for fault detection and recovery. Furthermore, lmp-wdm is 146 independent of any signalling protocol, so it can be used by both 147 distributed control system, such as GMPLS, and centralized 148 management systems. 150 Therefore, lmp-wdm supports the following CCAMP objectives: 152 . Define signalling protocols and measurement protocols such that 153 they support multiple physical path and tunnel technologies 154 (e.g., O-O and O-E-O optical switches, ATM and Frame Relay 155 switches, MPLS, GRE) using input from technology-specific 156 working groups such as MPLS, IPO, etc. 158 . Define signalling and measurement protocols that are 159 independent of each other. This allows applications other than 160 the signalling protocol to use the measurement protocol; it 161 also allows the signalling protocol to use knowledge obtained 162 by means other than the measurement protocol. 164 . Abstract link and path properties needed for link and path 165 protection. Define signalling mechanisms for path protection, 166 diverse routing and fast path restoration. Ensure that multi- 167 layer path protection and restoration functions are achievable 168 using the defined signalling and measurement protocols, either 169 separately or in combination. 171 . Define how the properties of network resources gathered by the 172 measurement protocol can be distributed in existing routing 173 protocols, such as OSPF and IS-IS. 175 JUSTIFICATION 177 draft-fredette-lmp-wdm-03.txt (lmp-wdm) is a protocol proposal 178 intended to satisfy the optical link interface (OLI) requirements 179 (draft-many-oli-reqts-00.txt). There has been a great deal of 180 interest in this work by both network operators and vendors, and the 181 requirements document has achieved consensus in the CCAMP working 182 group. 184 1. Introduction 186 Future networks will consist of photonic switches (PXCs), optical 187 crossconnects (OXCs), routers, switches, DWDM optical line systems 188 (OLSs), and optical add-drop multiplexors (OADMs) that use the GMPLS 189 control plane to dynamically provision resources and to provide 190 network survivability using protection and restoration techniques. 191 A pair of nodes (e.g., a PXC and an OLS) may be connected by 192 thousands of fibers. Furthermore, multiple fibers and/or multiple 193 wavelengths may be combined into a single bundled link. [LMP] 194 Defines the Link Management Protocol (LMP) to "maintain control 195 channel connectivity, verify component link connectivity, and 196 isolate link, fiber, or channel failures within the network." In 197 it's present form, [LMP] focuses on peer communications (eg. OXC-to- 198 OXC) as illustrated in Figure 1. In this document, extensions to 199 LMP for use with OLSs are proposed. These extensions are intended 200 to satisfy the "Optical Link Interface Requirements" described in 201 [OLI]. It is assumed that the reader is familiar with LMP as 202 defined in [LMP]. 204 +------+ +------+ +------+ +------+ 205 | | ----- | | | | ----- | | 206 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 207 | | ----- | | | | ----- | | 208 +------+ +------+ +------+ +------+ 209 ^ ^ 210 | | 211 +----------------------LMP----------------------+ 213 Figure 1: Base LMP Model 215 A great deal of information about a link between two OXCs is known 216 by the OLS. Exposing this information to the control plane via LMP 217 can improve network usability by further reducing required manual 218 configuration and also by greatly enhancing fault detection and 219 recovery. Fault detection is particularly an issue when the network 220 is using all-optical photonic switches (PXC). Once a connection is 221 established, PXCs have only limited visibility into the health of 222 the connection. Even though the PXC is all-optical, long-haul OLSs 223 typically terminate channels electrically and regenerate them 224 optically, which presents an opportunity to monitor the health of a 225 channel between PXCs. LMP-WDM can then be used by the OLS to 226 provide this information to the PXC using LMP-WDM. 228 In addition to the link information known to the OLS that is 229 exchanged through LMP-WDM, some information known to the OXC may 230 also be exchanged with the OLS through LMP-WDM. This information is 231 useful for alarm management and link monitoring (i.e., trace 232 monitoring). Alarm management is important because the 233 administrative state of a connection, known to the OXC (e.g., this 234 information may be learned through the Admin Status object of GMPLS 235 signaling [GMPLS]), can be used to suppress spurious alarms. For 236 example, the OXC may know that a connection is �up�, �down�, in a 237 �testing� mode, or being deleted (�deletion-in-progress�). The OXC 238 can use this information to inhibit alarm reporting from the OLS 239 when a connection is �down�, �testing�, or being deleted. 241 The model for extending LMP to OLSs is shown in Figure 2. 243 +------+ +------+ +------+ +------+ 244 | | ----- | | | | ----- | | 245 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 246 | | ----- | | | | ----- | | 247 +------+ +------+ +------+ +------+ 248 ^ ^ ^ ^ ^ ^ 249 | | | | | | 250 | +-----LMP-----+ +-----LMP----+ | 251 | | 252 +----------------------LMP----------------------+ 254 Figure 2: Extended LMP Model 256 In this model, an OXC may have multiple LMP sessions corresponding 257 to multiple peering relationships. At each level, LMP provides link 258 management functionality (i.e., control channel management, physical 259 connectivity verification, link property correlation) for that 260 peering relationship. For example, the OXC-OXC LMP session in 261 Figure 2 can be used to build traffic-engineering (TE) links for 262 GMPLS signaling and routing, and are managed as described in [LMP]. 263 At the transport level, the OXC-OLS LMP session (also shown in 264 Figure 2) is used to augment knowledge about the links between the 265 OXCs. The management of these LMP sessions is discussed in this 266 draft. It is important to note that an OXC may peer with one or more 267 OLSs and an OLS may peer with one or more OXCs. 269 Although there are many similarities between an OXC-OXC LMP session 270 and an OXC-OLS LMP session, particularly for control management and 271 link verification, there are some differences as well. These 272 differences can primarily be attributed to the nature of an OXC-OLS 273 link, and the purpose of OXC-OLS LMP sessions. As previously 274 mentioned, the OXC-OXC links can be used to provide the basis for 275 GMPLS signaling and routing at the optical layer. The information 276 exchanged over LMP-WDM sessions is used to augment knowledge about 277 the links between OXCs. 279 In order for the information exchanged over the OXC-OLS LMP sessions 280 to be used by the OXC-OXC session, the information must be 281 coordinated by the OXC. However, the two LMP sessions are run 282 independently and MUST be maintained separately. One critical 283 requirement when running an OXC-OLS LMP session is the ability of 284 the OLS to make a data link transparent when not doing the 285 verification procedure. This is because the same data link may be 286 verified between OXC-OLS and between OXC-OXC. The BeginVerify 287 procedure of [LMP] is used to coordinate the Test procedure (and 288 hence the transparency/opaqueness of the data links). 290 To maintain independence between the sessions, it MUST be possible 291 for the LMP sessions to come up in any order. In particular, it 292 MUST be possible for an OXC-OXC LMP session to come up without an 293 OXC-OLS LMP session being brought up, and vice-versa. 295 This draft focuses on extensions required for use with opaque 296 transmission systems. Work is ongoing in the area of fully 297 transparent wavelength routing; however, it is premature to identify 298 the necessary characteristics to exchange. That said, the protocol 299 described in this document provides the necessary framework in which 300 to advertise additional information as it is deemed appropriate. 302 Additional details about the extensions required for LMP are 303 outlined in the next section. 305 2. LMP Extensions for Optical Line Systems 307 As currently defined, LMP consists of four types of functions: 309 1. Control Channel Management 310 2. Link Verification 311 3. Link Summarization 312 4. Fault Management 314 All four functions are supported in LMP-WDM. Additionally, a trace 315 monitoring function is added. (Note: Other monitoring types will be 316 considered in a future release.) 318 In this document we follow the convention of [LMP] and use the term 319 "data link" to refer to either "component links" or "ports". 321 It is very important to understand the subtle distinctions between 322 the different types of links being considered in the extended LMP- 323 WDM. For example, in Figure 2 when OXC1 and OXC2 complete the 324 verify process, the links being verified are the end-to-end links 325 between the OXC's. It is the TE link composed of these "data links" 326 that are advertised in the routing protocols and used for the 327 purposes of connection setup. The verify procedure between OXC1 and 328 OLS1, on the other hand verifies the shorter link between these two 329 nodes. However, each of these shorter links is a segment of one of 330 the larger end-to-end links. The verify serves two functions: to 331 verify connectivity and exchange handles by which each data link is 332 referred. Furthermore, it is up to the OXC to correlate the handles 333 between the various LMP sessions. 335 Once a control channel has been established and the OXC-OLS 336 verification procedure has been completed successfully, the OXC and 337 OLS may exchange information regarding link configuration (i.e., 338 using the LinkSummary exchange). An OXC may also receive 339 notification regarding the operational status from an OLS (i.e., 340 using the ChannelStatus exchange). 342 In subsequent sections, specific additions are proposed to extend 343 LMP to work with OLSs. 345 2.1. Control Channel Management 347 As in [LMP], we do not specify the exact implementation of the 348 control channel; it could be, for example, a separate wavelength or 349 fiber, an Ethernet link, an IP tunnel through a separate management 350 network, or the overhead bytes of a data link. 352 The control channel management for OXC-OLS links is the same as for 353 OXC-OXC links, as described in [LMP]. The �LMP-WDM Support� flag in 354 the LMP Common Header is used to indicate support for the objects 355 defined in this draft. This informs the receiving node that the 356 LMP-WDM extensions will be used for the session. If the LMP-WDM 357 extensions are not supported by the node, it MUST reply to the 358 Config Message with a ConfigNack Message. 360 2.2. Link Verification 362 The Test procedure used with OLSs is the same as described in [LMP]. 363 The VerifyTransportMechanism (included in the BeginVerify and 364 BeginVerifyAck messages) is used to allow nodes to negotiate a link 365 verification method and is essential for transmission systems which 366 have access to overhead bytes rather than the payload. The VerifyId 367 (provided by the remote node in the BeginVerifyAck message, and used 368 in all subsequent Test messages) is used to differentiate Test 369 messages from different LMP sessions. 371 2.3. Link Summarization 373 As in [LMP], the LinkSummary message is used to synchronize the 374 Interface Ids and correlate the properties of the TE link. (Note 375 that the term �TE Link� originated from routing/signaling 376 applications of LMP, whereas this concept doesn�t necessarily apply 377 to an OLS. However, the term is used in this draft to remain 378 consistent with LMP terminology.) Additional Data Link sub-objects 379 are defined in this draft to extend the LinkSummary message to 380 include additional link characteristics. These sub-objects are 381 described in the following subsections. The link characteristics, 382 in general, are those characteristics needed by the control plane 383 for constraint-based routing in the selection of a path for a 384 particular connection. 386 The format of the Data Link Sub-Objects follows the format described 387 in [LMP] and is shown below for readability: 389 0 1 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ 392 | Type | Length | (Sub-object contents) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ 395 Type: 8 bits 397 The Type indicates the type of contents of the subobject. 399 Length: 8 bits 401 The Length field contains the total length of the sub-object in 402 bytes, including the Type and Length fields. The Length MUST 403 be at least 4, and MUST be a multiple of 4. 405 The following Link Characteristics are advertised on a per data link 406 basis. 408 2.3.1. Link Group ID 410 The main purpose of the Link Group ID is to reduce control traffic 411 during failures that affect many data links. A local ID may be 412 assigned to a group of data links. This ID can be used to reduce 413 the control traffic in the case of a failure by enabling the systems 414 to send a single message for a group instead of individual messages 415 for each member of the group. A link may be a member of multiple 416 groups. This is achieved by presenting multiple Link Group ID 417 Objects in the LinkSummary message. 419 The Link Group ID feature allows Link Groups to be assigned based 420 upon the types of fault correlation and aggregation supported by a 421 given OLS. From a practical perspective, the Link Group ID is used 422 to map (or group) data links into "failable entities" known only to 423 the OLS. If one of those failable entities fails, all associated 424 data links are failed and the OXC may be notified with a single 425 message. 427 For example, an OLS could create a Link Group for each laser in the 428 OLS. This group could be associated with data links during 429 discovery/initialization time. Multiple data links could be 430 associated with a single group (depending on the kind of 431 multiplexing supported in the system). If a laser fails, the OLS 432 can report a failure for the group. The OXC that receives the group 433 failure message can determine the associated link or links. Another 434 group could be assigned for a fiber to report all data links down 435 that are associated with that fiber if LOS is detected at the fiber 436 level. Depending on the physical OLS implementation, it may make 437 sense to allocate other groups, such as all data links on a 438 particular circuit card. With this method, the OXC only needs to 439 know about the externally visible data links. The OLS can associate 440 the data links with logical groups and the OXC doesn't need to know 441 anything about the physical OLS implementation or how data links are 442 multiplexed electrically or optically within the system. 444 The format of the Link Group ID sub-object (Type=TBD, Length=8) is 445 as follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | Link Group ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Link Group ID (cont) | (Reserved) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Link Group ID: 32 bits 457 Link Group ID 0xFFFFFFFF is reserved and indicates all data links 458 in a TE link. All data links are members of Link Group 0xFFFFFFFF 459 by default. 461 Reserved: 16 bits 463 Must be set to zero on transmit and ignored on receive. 465 2.3.2. Shared Risk Link Group Identifier (SRLG): 467 SRLGs of which the data link is a member. This information is 468 manually configured on an OLS by the user and may be used for 469 diverse path computation. 471 The format of the SRLG sub-object (Type=TBD) is as follows: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type | Length | SRLG value #1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | SRLG value #1(cont) | SRLG value #2 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | ............ | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | SRLG value #(N-1)(cont) | SRLG value #N | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | SRLG value #N(cont) | (Reserved) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Length: 8 bits 489 The length is (N+1)*4, where N is the number of SRLG values. 491 Shared Risk Link Group Value: 32 bits 493 List as many SRLGs as apply. 495 Reserved: 16 bits 497 Must be set to zero on transmit and ignored on receive. 499 2.3.3. Bit Error Rate (BER) Estimate 501 This Object provides an estimate of the BER for the data link. 503 The bit error rate (BER) is the proportion of bits that have errors 504 relative to the total number of bits received in a transmission, 505 usually expressed as ten to a negative power. For example, a 506 transmission might have a BER of "10 to the minus 13", meaning that, 507 out of every 10,000,000,000,000 bits transmitted, one bit may be in 508 error. The BER is an indication of overall signal quality. 510 The format of the BER Estimate subobject (Type=TBD; Length=4) is as 511 follows: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type | Length | BER | Reserved | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 BER: 8 bits 521 The exponent from the BER representation described above. For 522 example, if the BER is 10 to the minus X, the BER field is set to 523 X. 525 Reserved: 8 bits 527 Must be set to zero on transmit and ignored on receive. 529 2.3.4. Optical Protection 531 Whether the OLS protects the link internally. This information can 532 be used as a measure of quality of the link. It may be advertised 533 by routing and used by signaling as a selection criterion as 534 described in [GMPLS]. 536 The format of the Optical Protection subobject (Type=TBD; Length=4) 537 is as follows: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type | Length | Link Flags| Reserved | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Link Flags: 6 bits 547 Encoding for Link Flags can be found in [GMPLS]. 549 Reserved: 10 bits 551 Must be set to zero on transmit and ignored on receive. 553 2.3.5. Total Span Length: 555 The total distance of fiber in OLS. May be used as a routing metric 556 or to estimate delay. 558 The format of the Span Length sub-object (Type=TBD, Length=8) is as 559 follows: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length | Span Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Span Length (cont) | (Reserved) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Span Length: 32 bits 571 Total Length of the WDM span in meters expressed as an unsigned 572 integer. 574 Reserved: 16 bits 576 Must be set to zero on transmit and ignored on receive. 578 2.3.6. Administrative Group (Color) 580 The administrative group (or Color) to which the data link belongs. 582 The format of the Administrative Group sub-object (Type=TBD, 583 Length=8) is as follows: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type | Length | Administrative Group | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Administrative Group (cont) | (Reserved) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Administrative Group: 32 bits 595 A 32 bit value. 597 Reserved: 16 bits 599 Must be set to zero on transmit and ignored on receive. 601 2.4. Fault Management 603 Fault management consists of three major functions: 605 1. Fault Detection 606 2. Fault Localization 607 3. Fault Notification 609 The actual Fault Detection mechanisms are the responsibility of the 610 individual nodes and are not specified as part of this protocol. 611 Fault detection mechanisms may include such things as bit error rate 612 (BER) exceeding a threshold, loss of signal (LOS) and SONET/SDH- 613 level errors. It is the responsibility of the OLS to translate 614 these failures into OK, SF, or SD as described in LMP. 616 Running LMP-WDM on the OLS allows the OLS to notify an attached OXC 617 or router when it detects a fault. The OXCs and routers continue to 618 execute the fault localization procedure as currently specified in 619 [LMP]. The main enhancement when using LMP-WDM is that the OLS may 620 initiate the process (both downstream and upstream). It is 621 important to note that the OLS does not participate in end-to-end 622 fault localization as described in [LMP]. 624 The OLS may also execute its own fault localization process that may 625 allow it to determine the location of the fault much more 626 specifically than the OXCs can. For example, the OLS may be able to 627 pinpoint the fault to a particular amplifier along a set of fibers 628 that can span 1000's of kilometers. 630 To report data link failures and recovery conditions, LMP-WDM uses 631 the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and 632 ChannelStatusResponse Messages defined in [LMP]. 634 Each data link is identified by an Interface_ID. In addition, LMP- 635 WDM specifies a Link Group_ID that may be assigned to a group of 636 data links (see Section 2.3.1). The Link Group ID may be used to 637 reduce the control traffic by providing channel status information 638 for a group of data links. A new LINK GROUP_CHANNEL STATUS object is 639 defined below for this purpose. This object may be used in place of 640 the CHANNEL_STATUS objects described in [LMP] in the ChannelStatus 641 message. 643 2.4.1. LINK GROUP CHANNEL_STATUS Object 645 The LINK GROUP_STATUS object is used to indicate the status of the 646 data links belonging to a particular Link Group. The correlation of 647 data links to Group ID is made with the Link Group ID subobject of 648 the DATA_LINK Object. 650 The format of the LINK GROUP_CHANNEL STATUS object is as follows 651 (Class = 18, C-Type to be assigned by IANA): 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |N| C-Type | Class | Length | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Link Group_ID | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Channel_Status | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | : | 663 // : // 664 | : | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Link Group ID | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Channel Status | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Link Group_ID: 32 bits 673 Link Group ID 0xFFFFFFFF is reserved and indicates all data links 674 in a TE link. All data links are members of Link Group 0xFFFFFFFF 675 by default. 677 Channel_Status: 32 bits 679 The values for the Channel_Status field are defined in [LMP]. 681 This Object is non-negotiable. 683 2.5. Alarm Management 685 Alarm management is an important feature of LMP-WDM because it can 686 be used to suppress cascading and/or spurious alarms during normal 687 connection procedures. For example, the OXC may know that a 688 connection is �up�, �down�, in a �testing� mode, or being deleted 689 (�deletion-in-progress�). The OXC can use this information to 690 inhibit alarm reporting from the OLS when the state of a connection 691 changes in a controlled fashion. 693 Alarm management is controlled using the Active bit of the 694 CHANNEL_STATUS object (see [LMP]). 696 In the following, we describe how the Active bit can be used in 697 conjunction with the Admin Status object of [GMPLS] to manage alarms 698 during graceful connection deletion. 700 Consider the network of Figure 3 where a wavelength LSP has been 701 established using RSVP-GMPLS from OXC-A through OXC-B to OXC-C. To 702 support graceful deletion of the LSP, the Deletion in Progress bit 703 is set in the Admin Status object of a Path message that is 704 transmitted from OXC-A through OXC-B to OXC-C. This bit indicates 705 that �local actions related to LSP teardown should be taken.� As 706 part of the local actions for LSP teardown, each OXC should notify 707 it�s neighboring OLS(s) that the data link is now deactive. For 708 example, OXC-B should notify OLS-B1 and OLS-B2 that the link is 709 deactive before forwarding the Path message to the next node. This 710 ensures that when the connection is removed multiple alarms are not 711 triggered at each of the line systems. 713 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 714 | OXC |---| OLS | | OLS |---| OXC |---| OLS | | OLS |---| OXC | 715 | A |---| A1 |===| B1 |---| B |---| B2 |===| C1 |---| C | 716 | |---| | | |---| |---| | | |---| | 717 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 718 | | ^ ^ ||| ^ ^ | | 719 | +--------+ +--------+|+--------+ +--------+ | 720 | LMP-WDM LMP-WDM | LMP-WDM LMP-WDM | 721 +-------------------------------+------------------------------+ 722 GMPLS Signaling GMPLS Signaling 724 Figure 3: Alarm Management Example 726 2.6. Trace Monitoring 728 The trace monitoring features described in this section allow a PXC 729 to do basic trace monitoring on circuits by using the capabilities 730 on an attached OLS. 732 . An OLS Client may request the OLS to monitor a link for a 733 specific pattern in the overhead using the TraceMonitorReq 734 Message. An example of this overhead is the SONET Section 735 Trace message transmitted in the J0 byte. If the actual trace 736 message does not match the expected trace message, the OLS MUST 737 report the mismatch condition. 739 . An OLS client may request the value of the current trace 740 message on a given data link using the TraceReq Message. 742 2.6.1. TraceMonitor Message (MsgType = TBD) 744 The TraceMonitor message is sent over the control channel and is 745 used to request an OLS to monitor a data link for a specific trace 746 value. An OLS MUST respond to a TraceMonitor message with either a 747 TraceMonitorAck or TraceMonitorNack Message. 749 ::= 750 752 If supported by the hardware, traces of different types may be 753 monitored simultaneously (e.g., Section and Path trace messages may 754 exist simultaneously on the same data link). 756 2.6.1.1. TRACE Object 758 The format of the TRACE object is as follows (Class and C-Type to be 759 assigned by IANA): 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |N| C-Type | Class | Length | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Trace Type | Trace Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | 769 // Trace Message // 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 The Trace Object is non-negotiable. 775 Trace Type: 16 bits 777 The type of the trace message: 779 1 � SONET Section Trace (J0 Byte) 780 2 � SONET Path Trace (J1 Byte) 781 3 � SDH Section Trace (J0 Byte) 782 4 � SDH Path Trace (J1 Byte) 784 Other types TBD. 786 Trace Length: 16 bits 788 The Length in bytes of the trace message provided. 790 Trace Message: 792 Expected message. The valid length and value combinations are 793 determined by the specific technology (e.g., SONET or SDH) and 794 are beyond the scope of this document. The message MUST be 795 padded with zeros to a 32-bit boundary, if necessary. 797 2.6.2. TraceMonitorAck Message (MsgType = TBD) 799 The TraceMonitorAck message is used to indicate that all of the 800 Trace Objects in the TraceMonitor message have been received and 801 processed correctly. 803 The format is as follows: 804 ::= 806 The MESSAGE_ID_ACK object is defined in [LMP]. 808 2.6.3. TraceMonitorNack Message (MsgType = TBD) 810 The TraceMonitorNack message is used to indicate that the Trace 811 Object in the TraceMonitor message was not processed correctly. 812 This could be because the trace monitoring requested is not 813 supported or there was an error in the value. 815 The format is as follows: 817 ::= 818 820 The MESSAGE_ID_ACK object is defined in [LMP]. 822 The TraceMonitorNack message uses the ERROR_CODE C-Type, 824 2.6.3.1. ERROR_CODE Class 826 C-Type = 20 (see [LMP]) 828 LMP-WDM defines the following new error code bit-values: 830 TBD1 = Unsupported Trace Type 831 TBD2 = Invalid Trace Message 833 All other values are Reserved. 835 Multiple bits may be set to indicate multiple errors. 837 This Object is non-negotiable. 839 2.6.4. TraceMismatch Message (MsgType = TBD) 841 The TraceMismatch message is sent over the control channel and is 842 used to report a trace mismatch on a data link for which trace 843 monitoring was requested. 845 A neighboring node that receives a TraceMismatch message MUST 846 respond with a TraceMismatchAck message. The format is as follows: 848 ::= 849 [ ...] 851 The LOCAL_INTERFACE_ID object is defined in [LMP]. The 852 LOCAL_INTERFACE_ID in this message is the local Interface Id of the 853 link that has a trace mismatch. A trace mismatch for multiple 854 LOCAL_INTERFACE_ID's may be reported in the same message. 856 2.6.5. TraceMismatchAck Message (MsgType = TBD) 858 The TraceMismatchAck message is used to acknowledge receipt of a 859 TraceMismatch message. 861 The format is as follows: 862 ::= 864 The MESSAGE_ID_ACK object is defined in [LMP] and must be copied 865 from the TraceMismatch Message being acknowledged. 867 2.6.6. TraceReq Message (MsgType = TBD) 869 The TraceReq message is sent over the control channel and is used to 870 request the current trace value of indicated data links. 872 A node that receives a TraceReq message MUST respond with a 873 TraceReport message. The format is as follows: 875 ::= 876 878 The format of the TRACE_REQ object is as follows: 880 0 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 |N| C-Type | Class | Length | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Trace Type | (Reserved) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Trace Type: Defined in Section 2.6.1.1. 890 2.6.7. TraceReport Message (MsgType = TBD) 892 The TraceReport message is sent over the control channel after 893 receiving a TraceReq message. 895 ::= 897 The TraceReport message MUST include a TRACE Object (as described in 898 Section 2.6.1.1) for the link requested. 900 2.6.8. TraceReqNak Message (MsgType = TBD) 902 The TraceReqNak message is sent over the control channel after 903 receiving a TraceReq message. 905 ::= 906 908 The TraceReqNak message MUST include an ERROR_CODE Object (as 909 described in Section 2.6.3) for the link requested. 911 2.6.9. InsertTraceReq Message (MsgType = TBD) 913 The InsertTraceReq message is sent over the control channel and is 914 used to request an OLS to send a specific trace message on a data 915 link. An OLS MUST respond to a InsertTraceReq message with either a 916 InsertTraceAck or InsertTraceNak Message. 918 ::= 919 921 2.6.10. InsertTraceAck Message (MsgType = TBD) 923 The InsertTraceAck message is used to indicate that the TRACE Object 924 in the InsertTrace message has been received and processed 925 correctly. 927 The format is as follows: 928 ::= 930 The MESSAGE_ID_ACK object is defined in [LMP]. 932 2.6.11. InsertTraceNack Message (MsgType = TBD) 934 The InsertTraceNack message is used to indicate that the Trace 935 Object in the InsertTrace message was not processed correctly. This 936 could be because the trace monitoring requested is not supported or 937 there was an error in the value. 939 The format is as follows: 940 ::= 941 943 The MESSAGE_ID_ACK object is defined in [LMP]. The ERROR_CODE 944 Object usage is described in Section 2.6.3.1. 946 3. Security Considerations 948 General LMP security issues are discussed in [LMP]. As in [LMP], 949 LMP-WDM exchanges may be authenticated using the Cryptographic 950 authentication option. MD5 is currently the only message digest 951 algorithm specified. The InsertTraceReq and TraceMonitor messages 952 introduced in this document present an opportunity for an intruder 953 to disrupt transmission. Authentication of messages is recommended 954 if the control network itself is not secure. 956 4. Work Items 958 The following work items have been identified. They will be 959 addressed in a future version of this draft: 961 1. Error messages may be needed in response to some of the defined 962 messages. 964 2. More discussion on Trace Monitoring procedures is needed. 966 3. Provide description of procedures and interactions for running 967 LMP and LMP-WDM on the same link. Include description of how 968 control over link transparency works during the Verify 969 procedure. 971 4. Determine whether some functions are optional and, if so, 972 provide a capability negotiation mechanism. 974 5. References 976 [GMPLS] Berger, L., Ashwood-Smith, Peter, editors, 977 "Generalized MPLS - Signaling Functional Description", 978 Internet Draft, draft-ietf-mpls-generalized-signaling- 979 02.txt, (work in progress), March 2001. 981 [Bra96] Bradner, S., "The Internet Standards Process -- 982 Revision 3," BCP 9, RFC 2026, October 1996. 984 [DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al., 985 "Interworking between Photonic (Optical) Switches and 986 Transmission Systems over Optical Link Interface (OLI) 987 using Extensions to LMP", OIF Contribution 988 oif2000.254, (work in progress), November 2000. 990 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 991 in MPLS Traffic Engineering," Internet Draft, draft- 992 kompella-mpls-bundle-02.txt, (work in progress), July 993 2000. 995 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 996 Extensions in Support of Generalized MPLS," Internet 997 Draft, draft-kompella-ospf-extensions-00.txt, (work in 998 progress), July 2000. 1000 [LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, 1001 Y., Berger, L., Saha, D., Basak, D., Sandick, H., 1002 Zinin, A., "Link Management Protocol (LMP)", Internet 1003 Draft, draft-ietf-ccamp-lmp-02.txt, (work in 1004 progress), July 2001. 1006 [OLI] Fredette, A., Editor, "Optical Link Interface 1007 Requirements", Internet Draft, draft-many-oli-reqts- 1008 00.txt, (work in progress), June 2001. 1010 [SDH] ITU-T G.707, "Network node interface for the 1011 synchronous digital hierarchy (SDH)", 1996. 1013 [SONET] GR-253-CORE, "Synchronous Optical Network (SONET) 1014 Transport Systems: Common Generic Criteria", Telcordia 1015 Technologies, Issue 3, September 2000 1017 [T.50] ITU-T T.50, "International Reference Alphabet (IRA) 1018 (formerly International Alphabet No. 5 or IA5) 1019 Information technology 7-bit coded character set for 1020 information interchange.", 1992. 1022 6. Author's Addresses 1024 Osama S. Aboul-Magd Rohit Goyal 1025 Nortel Networks Axiowave Networks 1026 P.O. Box 3511, Station C 100 Nickerson Road 1027 Ottawa, Ontario, Canada Marlborough, MA 01752 1028 K1Y 4H7 email: rgoyal@axiowave.com 1029 Phone: 613-763-5827 1030 email: osama@nortelnetworks.com Hirokazu Ishimatsu 1031 Japan Telecom 1032 Stuart Brorson 2-9-1 Hatchobori. Chuo-ku, 1033 Axiowave Networks Tokyo, 104-0032 Japan 1034 100 Nickerson Road email: hirokazu@japan- 1035 Marlborough, MA 01752 telecom.co.jp 1036 email: sdb@axiowave.com 1037 Monika Jaeger 1038 Sudheer Dharanikota T-systems 1039 Nayna Networks, Inc. Monika.Jaeger@t-systems.de 1040 157 Topaz Drive, 1041 Milpitas, CA 95035 Ram Krishnan 1042 email: sudheer@nayna.com Axiowave Networks 1043 100 Nickerson Road 1044 John Drake Marlborough, MA 01752 1045 Calient Networks email: ram@axiowave.com 1046 5853 Rue Ferrari 1047 San Jose, CA 95138 Jonathan P. Lang 1048 email: jdrake@calient.net Calient Networks 1049 Court25 Castilian Drive 1050 David Drysdale Goleta, CA 93117 1051 Data Connection Ltd email: jplang@calient.net 1052 dmd@dataconnection.com 1053 Raghu Mannam 1054 W. L. Edwards Hitachi Telecom (USA), Inc. 1055 iLambda Networks rmannam@hitel.com 1056 Aspen, CO 1057 email: texas@ilambda.com Eric Mannie 1058 Ebone (GTS) 1059 Adrian Farrel (Movaz Networks) Terhulpsesteenweg 6A 1060 Movaz Networks, Inc. 1560 Hoeilaart 1061 7926 Jones Branch Drive, Belgium 1062 Suite 615 Email: eric.mannie@gts.com 1063 McLean, VA 22102 1064 email: afarrel@movaz.com Dimitri Papadimitriou 1065 Alcatel 1066 Andre Fredette Francis Wellesplein 1, 1067 PhotonEx Corporation B-2018 Antwerpen, Belgium 1068 8C Preston Court email: dimitri.Papadimitriou 1069 Bedford, MA 01730 @alcatel.be 1070 email: fredette@photonex.com 1071 Jagan Shantigram Yong Xue 1072 PhotonEx Corporation UUNET/WorldCom 1073 8C Preston 22001 Loudoun County Parkway 1074 Bedford, MA 01730 Ashburn, VA 20148 1075 email: jagan@photonex.com email: yxue@uu.net 1077 Ed Snyder Lucy Yong 1078 PhotonEx Corporation Williams Communications 1079 8C Preston Court 2 East First Street 1080 Bedford, MA 01730 Tulsa, OK 74172 1081 email: esnyder@photonex.com lucy.yong@wilcom.com 1083 George Swallow John Yu 1084 Cisco Systems, Inc. Zaffire, Inc 1085 250 Apollo Drive 2630 Orchard Parkway 1086 Chelmsford, MA 01824 San Jose, CA 95134 1087 Email: swallow@cisco.com email: jzyu@zaffire.com 1089 Gopala Tumuluri 1090 Calient Networks 1091 5853 Rue Ferrari 1092 San Jose, CA 95138 1093 email: krishna@calient.net