idnits 2.17.1 draft-sahay-ccamp-ntip-01.txt: ** The Abstract section seems to be numbered 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == There is 1 instance 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 17 longer pages, the longest (page 9) being 61 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 127 has weird spacing: '... Side sid...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2001) is 8321 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 section? '1' on line 25 looks like a reference -- Missing reference section? '2' on line 57 looks like a reference -- Missing reference section? '3' on line 412 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP WG V. Sahay 3 B. Narayanan 4 Internet Draft R. Ramaswami 5 Document: draft-sahay-ccamp-ntip-01.txt O. Aboul-Magd 6 B. Jamoussi 7 Nortel Networks 9 R. Jain 10 S. Dharanikota 11 Nayna Networks 13 R. Hartani 14 Caspian Networks 16 July 2001 18 Network Transport Interface Protocol (NTIP) for Photonic 19 Cross Connects (PXC) 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026 [1]. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. Internet-Drafts are draft documents valid for a maximum of 30 six months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 1. Abstract 42 This draft describes the transport network interface protocol (NTIP) 43 for photonic cross connects (PXC). NTIP is implemented between a PXC 44 and transport network element (TNEs), also known as line systems. 45 NTIP is a protocol that uses TCP/IP for the transport of information 46 related to defect notification, trace monitoring, adjacency 47 discovery, and diagnostic messages between directly attached PXC and 48 TNE. The use of TCP as the transport protocol ensures reliable and 49 in-sequence delivery of NTIP messages. 51 2. Conventions used in this document 53 Sahay Expires January 2002 1 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 56 this document are to be interpreted as described in RFC-2119 [2]. 58 3. Introduction 60 Fast restoration of failed light paths is critical for PXCs and it 61 requires support for fast and accurate failure detection. Most PXCs 62 do not look into the optical signals that flow through them. Some 63 can detect presence or loss of light on a port. However presence of 64 light does not necessarily mean that the light path is fine. For 65 example when a link fails, generators between the point of failure 66 and the PXC may inject an alarm indication signal (AIS) on a light 67 signal. Unless the PXC decodes the framing of the light signal 68 (possibly using some electrical circuitry), AIS will appear as 69 presence of light. Also, some of the DWDM equipment (also called 70 Transport Network Elements in this document) can control the 71 switching ON and OFF of the AIS by configuration (or on demand). This 72 feature can be leveraged to the advantage of the faster fault 73 detection and hence the recovery times. 75 Unlike the PXC, the transport network elements (TNE) attached to it 76 are aware of their equipment failure as well as the quality and 77 framing of the light paths passing through them. Failure information 78 can be dynamically conveyed from the TNE to the PXC using out of 79 band IP messaging. 81 The transport network interface protocol (NTIP) defines the set of 82 messages and the transport mechanism used for the exchange of 83 failure conditions. NTIP is implemented between the PXC and the TNE. 84 NTIP is an IP message handshake transported over an IP network. The 85 implementation of NTIP between TNE and PXC achieves the following 86 goals: 88 - Defect Notification: NTIP is used by the TNE to relay failure 89 conditions and precise link, fiber, and equipment status 90 notification to PXC. Defect reporting can be both event-driven 91 (e.g., link failures), polling-driven (e.g., regular link sanity 92 checks) or time-driven (e.g., periodic). 94 - Trace Monitoring: A PXC can use NTIP to request a TNE to monitor a 95 certain pattern in the overhead of a light path. This capability 96 could be used by PXC for validating light path identity. 98 - Diagnostics: NTIP could be used by OXC to request a TNE to perform 99 diagnostics on any port or channel. 101 - Adjacency Discovery: NTIP could be used by both PXC and TNE to 102 send and receive in band signals for automatic discovery of their 103 optical connectivity. 105 Sahay Expires January 2002 2 106 This draft describes NTIP procedures and messages to achieve its 107 design goals. 109 4. Reference Model 111 The current generation of PXCs will interoperate with opaque line 112 systems such as SONET regenerators, wavelength translators, etc. 113 Eventually when enough transparent line systems are deployed, PXCs 114 will interwork with them leading to an all optical network (AON). 115 The need for NTIP exists in both cases. The following reference 116 model focuses on interoperation of PXCs with opaque line systems. 118 A reference model is shown in Figure 1. TNE are used to connect PXC 119 ports to the transport system. TNE could be a set of OEO devices 120 followed by a DWDM mux as shown in Figure 1. A TNE regenerates the 121 signal coming from the PXC and might be capable of translating the 122 wavelength. The key features of a TNE in the reference model are its 123 ability to detect defects on its ports and to communicate defect 124 information back to the PXC using NTIP. 126 Drop Line 127 Side side 128 | | 129 | | 130 +---------+| TNE | |\ /| TNE +---------+ 131 | +---|V +---+V | \ / | +---+ |---+ | 132 | |Por|->| |->| \ / |<-| |<-|Por| | 133 | | t| |---| | \ / | |---| | t| | 134 | | |<-| |<-| \ / |->| |->| | | 135 | +---| +---+ | \=====>/ | +---+ |---+ | 136 | | | /<=====\ | | PXC | 137 | PXC +---| +---+ | / \ | +---+ |---+ | 138 | |Por|->| |->| / \ |<-| |<-|Por| | 139 | | t| |---| | / \ | |---| | t| | 140 | | |<-| |<-| / DWDM MUX \ |->| |->| | | 141 | +---| +---+ |/ \| +---+ |---+ | 142 |=========| |=========| 143 |controlle| +===+ +===+ |controlle| 144 | r |<>| | | |<>| r | 145 +---------+^ +===+ +===+ ^+---------+ 146 | TNE TNE | 147 | controller controller | 148 NTIP NTIP 150 PXC = Photonic CrossConnect TNE = Transport Network Element 151 TX = Transmit RX = Receive 153 FIGURE 1: PXC to TNE Reference Configuration 155 Each PXC port consists of two unidirectional fibers, one for input 156 (RX) and one for output (TX). Four TNE ports are associated with 157 each PXC port (RX and TX). The TNE port that is connected to PXC is 158 referred to as drop-side port, and the one that is connected to the 160 Sahay Expires January 2002 3 161 line is called the line-side port. Figure 1 shows that a PXC will 162 communicate with several TNEs. On the other hand, a TNE only 163 communicates with a single PXC. 165 A TNE can detect failures on signals it receives. Additionally some 166 TNEs may be able to detect certain failures on their output ports 167 such as laser failure. 169 5. NTIP Overview 171 5.1 Configuration 173 Whenever automatic discovery is not available, a PXC is provisioned 174 with information on how its ports are connected to TNE. It is also 175 provisioned with the primary and the secondary IP addresses of each 176 TNE connected to it. 178 NTIP defines a set of configurable parameters such as protocol 179 timers, retry counts, etc. Those parameters could be assigned 180 default values or allowed to be set as needed or negotiated. 182 5.2 Registration 184 As a TNE starts up, it registers with the PXC whose address is 185 configured in it. A TNE registers by opening a TCP session with the 186 PXC, and sending a registration request message. TNE registration 187 allows PXC to create its internal context structure for this 188 particular TNE. 190 5.3 Keep Alive 192 NTIP utilizes keep alive messages. Keep alive messages are exchanged 193 periodically between TNE and PXC to verify the sanity of the 194 connection. The keep alive message interval is a configurable 195 parameter. 197 5.4 Automatic Discovery 199 A PXC might have hundreds or even thousands of ports. Manual entries 200 of port adjacency between PXC and TNEs connected to it is tedious 201 and error prone. Furthermore manual entry has to be repeated every 202 time there is change in adjacency due to, for instance, re-cabling. 204 One application of the NTIP interface is for use in automatic 205 adjacency discovery between PXC and TNEs. For that purpose it is 206 assumed that the TNE is aware of its ports mapping, i.e. the mapping 207 between its drop side TX and RX ports, and its line side ports. This 208 mapping is mad available using NTIP to the auto discovery process 209 (ADP). 211 The TNE drop side port is supposed to operate in one of two modes, 212 Pass-through and Insert. In the Insert mode the drop side TX inserts 213 an identity pattern into the signal overhead, e.g. J0. The PXC is 215 Sahay Expires January 2002 4 216 made aware of the TNE port identity patterns over the NTIP interface 217 using a MappingTable message. In the Pass-through mode, the TNE drop 218 side TX passes the signal without modification. 220 The auto discovery process starts with the PXC port establishing a 221 cross connect to a well-known Test RX as shown in Figure 2. The PXC 222 then sends a ModeSwitch message to the TNE to switch the TNE drop 223 side TX mode to the Insert mode. The TNE starts inserting its 224 identity pattern (could be a system wide unique id or a trail trace 225 id). 227 +-------------+ +----+----+ 228 | |---->| RX | TX |---> 229 | | +----+----+ 230 | PXC | 231 | | +----+----+ 232 | |<----| TX | RX |<--- 233 | | +----+----+ 234 +-------------+ 235 | ^ <-- NTIP--> 236 | | 237 V | 238 +---+ +---+ 239 | | | | 240 +---+ +---+ 242 Test Test 243 RX TX 245 Figure 2: Auto Discovery Configuration 247 The Test RX is requested to report the Identity message it sees. The 248 ADP maps the identity message to the drop side TX port id and the 249 PXC port id. To verify mapping, the Test TX is requested to send the 250 same identity pattern to the TNE drop side RX over NTIP using the 251 discovered PXC port. The TNE drop side RX verify the received 252 identity pattern and reports match pr mismatch. 254 The Test TX/RX could be internal or external to the PXC. In the case 255 of external Test TX/RX, communication would be done over NTIP 256 interface. 258 The procedure for auto-discovery is also applicable for link 259 verification. 261 5.5 Defect Monitoring 263 Defect monitoring is initiated by the PXC by telling the TNE which 264 ports to monitor for defects (signal degradation, loss of light, 265 etc.). Defect monitoring will be initiated by the PXC after setting 266 a light path through a TNE port. PXC terminates defect monitoring on 267 a port before it disconnects the light path on that port. 269 Sahay Expires January 2002 5 270 5.6 Trace Monitoring 272 Trace monitoring ensures that a light path is connected to the 273 correct client. A trace (light path Id) is injected by the client in 274 the light path. After setting up a light path, PXC will request TNE 275 to match the supplied trace id with that in the light path. The TNE 276 informs the PXC in case of a mismatch. 278 Trace Id is a pattern that can be injected and monitored in a light 279 path without affecting its payload. A few different alternative ways 280 of implementing it are possible. Trace Id may be injected in wrapper 281 or as a pilot tone. NTIP supports all of them. 283 The PXC discontinue the trace monitoring process for a particular 284 light path before deleting it. 286 5.7 Status Request/Response 288 Status request is initiated by the PXC and is triggered by an NTIP 289 user application, e.g. NMS. Status response contains the status of 290 the requested to TNE ports. It is sent by the TNE in response to 291 status request. 293 5.8 Batching of Messages 295 To reduce message traffic, TNE can pack several defect notification 296 messages into a single message. Latency could be experienced as a 297 result of batching since TNE has to hold off sending defects for an 298 amount of time necessary to collect enough defects. 300 5.9 Resynchronization 302 Resynchronization is needed every time an NTIP session restarts. An 303 NTIP session could restart due to TCP connection failure, PXC 304 restart due to internal reasons, e.g. control plan restart or PXC 305 restart, TNE restart, or as a result of a deletion of the NTIP 306 session due to time out. 308 Each TNE keeps track of its NTIP session. If the session is deleted, 309 it attempts to create another session over TCP/IP periodically. The 310 time it waits before initiating a second attempt is a configurable 311 parameter. 313 Once TNE succeeds in creating a TCP connection with PXC, it repeats 314 the registration procedure as mentioned in section 5.2. Upon 315 receiving the registration request, the PXC goes into a 316 resynchronization phase requesting an update on the port status of 317 all TNE ports that it is interested in. The PXC confirms the end of 318 the synchronization phase to the TNE when it receives the status of 319 all the requested ports. 321 Resynchronization helps the reporting of failure events that would 322 have been missed by the PXC due to the NTIP session being down. It 324 Sahay Expires January 2002 6 325 also allows the TNE not to remember the defects monitoring commands 326 given before resynchronization. 328 5.10 TNE to PXC Transport 330 A single high availability router/switch is recommended for 331 connecting TNE to PXC. This transport arrangement is referred to as 332 NTIP transport network. TNE defect messages are required to reach 333 the PXC with little delays. It is recommended that the NTIP network 334 supports the priority handling of packets, e.g. differentiated 335 services. Messages related to defect reporting are transported with 336 high priority. All other messages, that are not time critical, are 337 transported using a lower priority. 339 NTIP messages are transported reliably using TCP as the transport 340 protocol. The use of TCP also ensures in-sequence delivery of NTIP 341 messages, hence relieving the protocol developer from creating an 342 additional layer for reliable delivery. 344 Figure 3 shows the logical connectivity between PXC and TNE. 346 +-----+ +-----+ 347 | | +--------------+ +----+ | 348 | | | |-------+----+ |--+ 349 | PXC |---| IP Network |-------| |-+ 350 | | | | +----+ 351 | | +-------------+ TNEs 352 +-----+ 353 |<---------------------------->| 354 TCP Session 356 FIGURE 3: PXC-TNE Logical Connectivity 358 Figure 3 emphasizes the fact that a PXC communicates with several 359 TNEs while a TNE only communicates with a single PXC. 361 5.11 Defect Types 363 A TNE will report the following defects to PXC. 365 - Signal Degrade (SD): TNE reports this type of failure when the 366 light signal on one of its ports degrades below a configured 367 threshold. 369 - Signal Fails (SF): TNE reports SF to PXC when the incoming signal 370 fails on one of its ports. 372 - AIS: TNE reports AIS to PXC when it detects AIS-LINE on one of its 373 ports. 375 - Trace Mismatch: TNE reports Trace Mismatch when it mismatch is 376 detected by one of its ports between an injected pattern and the 377 expected pattern. 379 Sahay Expires January 2002 7 380 - Equipment Failure: TNE will notify PXC of equipment failure (e.g. 381 OEO card or laser failure on the transport side) and the port 382 number that suffered the failure. 384 6.0 NTIP and OLI Requirements 386 The requirements for the interface between PXC and the line system, 387 denoted as OLI (Optical Link Interface), have been discusses in [3]. 388 Most of those requirements have been taken from the earlier version 389 of this draft that was presented back in March during the IETF 50 390 meeting. In this section we discuss how far NTIP satisfies those 391 requirements. 393 6.1 General OLI Characteristics 395 General OLI requirements are reliabile, secure, and simple. NTIP 396 meets the reliability and security requirements by employing TCP as 397 its transport mechanism. TCP provide reliable and orderly 398 transmission of NTIP messages. Furthermore it provides a flow 399 control mechanism that allows for bulk transmission of NTIP 400 messages. The TCP window mechanism paces messages for cases where 401 the traffic volume increase for instance due to, for instance, re- 402 synchronization. 404 Line systems (TNEs) do not usually have much memory, and can only 405 keep a limited amount of state. NTIP achieves simplicity by 406 establishing a master-slave, as opposed to peer, relationship 407 between the PXC and TNEs. This minimizes the amount of states kept 408 at the TNE and makes efficient used of the limited memory available. 410 6.2 OLI Functionality 412 OLI basic functionality as defined in [3] are: neighbor discovery, 413 control channel maintenance, re-synchronization, connectivity 414 discovery, fault management, and link property information. 416 Neighbor discovery and control channel maintenance are achieved in 417 NTIP by means of a simple registration and keep alive procedures. 419 Connectivity discovery has been discussed in section 5.4. It allows 420 for the automatic discovery and mapping between PXC ports and TNE 421 ports. 423 Fault management and re-synchronization have always been the main 424 focus of NTIP as discussed in a previous revision of this draft. 425 Fault management includes fault notification and trace monitoring, 426 both have originally been introduced in a previous revision of this 427 draft. NTIP introduced the notion of priority handing of fault 428 notification messages to expedite light path recovery and 429 restoration in the order of few tens ms. 431 Sahay Expires January 2002 8 432 Trace monitoring has ingeniously been introduced by NTIP and has 433 been adopted as one of the main requirements of OLI. 435 Most of the link property information, e.g. SRLG and span length can 436 be configured. If necessary they can be added to NTIP with minor 437 modifications. 439 7.0 NTIP Messages and Procedures 441 All NTIP messages start with the following two fields: 443 NTIP Vers: 444 2-byte field that contains the NTIP protocol version number. 446 Type: 447 2-byte field that contains the message type 449 The version number provides the features supported by the other side 450 of the NTIP communication. It is only verified at the establishment 451 of NTIP session, and is used during registration and 452 resynchronization states. 454 7.1 Registration Message 456 The format of the Registration Message is: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | NTIP Vers | Type | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 + + 465 | | 466 + TNE Model Number + 467 | | 468 + + 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Type: 473 Type = REG-REQ 475 TNE Model Number: 476 16-byte filed that specifies the TNE model number 478 Procedure: 479 Registration Message is sent by the TNE to the PXC at start up. If 480 a PXC receives a Registration Message with a different NTIP Vers 481 than expected it may take one of the following actions: 483 - Reject the registration request 485 Sahay Expires January 2002 9 486 - Reject the registration request if the received NTIP Vers differs 487 by more than an allowed difference. If the difference is 488 acceptable, then the message set common to the two versions will 489 be supported. 491 7.2 Registration Complete Message 493 The format of the Registration Complete Message is: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | NTIP Vers | Type | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Type: 502 Type = REG-COMPLETE 504 Procedure: 505 The Registration Complete Message is sent by PXC to TNE indicating 506 a successful completion of the registration. The message is sent 507 only during the initial synchronization phase. 509 7.3 KeepAlive Message 511 The format of the KeepAlive Message is: 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 | NTIP Vers | Type | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Type: 520 Type = KEEP-ALIVE-REQ 522 Procedure: 523 The KeepAlive Message is sent by the TNE to PXC every T-keep-alive- 524 interval seconds (the default is 60 seconds). If PXC does not receive 525 a KeepAlive Message every T-keep-alive-timeout (t-keep-alive-timeout 526 = 3*T-keep-alive-interval), it takes down the NTIP session. 528 7.4 KeepAlive Response Message 530 The format of the KeepAlive Response Message is: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | NTIP Vers | Type | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Type: 540 Sahay Expires January 2002 10 541 Type = KEEP-ALIVE_RES 543 Procedure: 544 The KeepAlive Response Message is sent by PXC to TNE in response to 545 a KeepAlive Message. 547 7.5 Monitor Request Message 549 The format of the Monitor Request Message is: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | NTIP Vers | Type | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Length | Reserved | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | No. of Ports | Reserved | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Port Address | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |AR |DM | TType |MT | Tr Len | Reserved | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 ~ Trace ID ~ 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 ~ ~ 570 | | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Port Address | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |AR |DM | TType |MT | Tr Len | Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | | 577 ~ Trace ID ~ 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Type: 582 Type = MON-REQ 584 No. of Ports: 585 2-byte field that contains the number of ports reported in this 586 message. 588 Port Address: 589 4-byte field that is formatted as: 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Sahay Expires January 2002 11 594 | shelf | slot | Sub Slot | port | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Alarm Reporting, AR: 598 2-bit field that indicates start, stop, or no change to alarm 599 reporting. 601 Defect Monitoring, DM: 602 2-bit field that indicates start, stop, or no change to failure 603 monitoring. 605 Trace Type, TType: 606 4-bit used to indicate the trace type. Possible types are, pilot 607 tone, wrapper, J0 bytes. 609 Monitor of Trace, MT: 610 2-bit field that indicates start, stop, or no change to trace 611 monitoring 613 Trace Length, Tr Len: 614 6-bit field that indicates the length of the monitored trace. 616 Trace ID: 617 Up to 63 bytes. It defines the trace to be monitored. User could 618 treat the Trace ID as ASCII or binary 620 Procedure: 621 The Monitor Request Message is sent by PXC to TNE. After setting a 622 light path through TNE, PXC will send Monitor Request Message 623 indicating the start of defect monitoring and the list of monitored 624 ports. Before disconnecting a light path, PXC sends Monitor Request 625 Message with DM set to stop indicating the end of the defect 626 monitoring process. 628 The Monitor Request Message is also used for the start and the stop 629 of alarm reporting and trace monitoring. Upon the start of trace 630 monitoring, the PXC supplies the Trace ID to be compared to that in 631 the light path (say, in SONET J0 bytes, or in wrapper, or pilot 632 tone). Trace ID is not included in the Monitor Request Message when 633 MT is set to stop or no change. 635 7.6 Defect Notification 637 The format for the Defect Notification Message is: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | NTIP Vers | Type | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Length | Reserved | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Sahay Expires January 2002 12 648 | No. of Ports | Reserved | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Port Address | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | FS | FT | Reserved | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 ~ ~ 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Port Address | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | FS | FT | Reserved | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Type: 664 Type = DEFECT-NOTIFICATION 666 Failure Status, FS: 667 2-bit field that indicates fail or clear. 669 Failure Type, FT: 670 1-byte filed that indicates the failure (defect) type as discussed 671 in section 5.10. 673 Procedure: 674 The Defect Notification Message is sent by the TNE in response to a 675 PXC Monitor Request Message. The Defect Notification Message is 676 sent with the highest possible priority to reach the destination 677 PXC in a timely fashion. 679 7.7 Status Request Message 681 The format of the Status Request Message is: 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | NTIP Vers | Type | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Length | Reserved | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | No. of Ports | Reserved | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Port Address | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Tag | Reserved | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | | 697 ~ ~ 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Sahay Expires January 2002 13 702 | Port Address | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Tag | Reserved | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Type: 708 Type = STATUS-REQ 710 Tag: 711 A 4-bit field that is used for message identification 713 Procedure: 714 The Status Request Message is sent by PXC to TNE to solicit the 715 status of some or all of the TNE ports. Status Request Message 716 could also be sent to query the status of a previously issued 717 Monitor Request Message. 719 7.8 Status Response Message 721 The format of the Status Response Message is: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | NTIP Vers | Type | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Length | Reserved | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | No. of Ports | Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Port Address | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Tag | CStat | Dyn Stat | Reserved | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | 737 ~ ~ 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Port Address | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Tag | CStat | Dyn Stat | Reserved | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Type: 746 Type = STATUS-RESP 748 Configuration Status, CStat: 749 4-bit field that indicates the provisioned state of a TNE port. It 750 indicates whether the port is enabled or disabled. 752 Dynamic State, Dyn Stat: 754 Sahay Expires January 2002 14 755 1-byte field that indicates the failure type experience by a TNE 756 port. 758 Procedure: 759 The Status Response Message is sent from TNE to PXC. A TNE sends a 760 Status Response Message in response to a Status Request Message. 761 For each port requested, the Status Response Message includes a 762 configuration status (enabled or disabled), and a dynamic port 763 defect status that specify the failure type as discussed in 764 section 5.10. 766 7.9 Configuration Update 768 The format of the Configuration Update Message is: 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | NTIP Vers | Type | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Length | Reserved | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | No. of Ports | Reserved | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Port Address | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | CStat | Dyn Stat | Reserved | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | 784 ~ ~ 785 | | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Port Address | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | CStat | Dyn Stat | Reserved | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Type: 793 Type = CONFIG-UPDATE 795 Procedure: 796 The Configuration Update Message is sent unsolicited by TNE to 797 PXC. It is used for dynamically modifying the configuration while 798 in operation. 800 8. Security Considerations 802 This draft does not introduce any new security issues. 804 9. References 806 Sahay Expires January 2002 15 807 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 808 9, RFC 2026, October 1996. 810 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 811 Levels", BCP 14, RFC 2119, March 1997 813 3 A. Fredette, Editor, � Optical Link Interface Requirements�, 814 draft-many-oli-reqts-00.txt, work in progress, June 2001 816 10. Author's Addresses 818 Vasant Sahay 819 Nortel Networks 820 2305 Mission College Blvd 821 Santa Clara, CA 95054, USA 822 Phone: 408-565-4601 823 E.mail: vasants@nortelnetworks.com 825 Rajiv Ramaswami 826 Nortel Networks 827 2305 Mission College Blvd 828 Santa Clara, CA 95054, USA 829 Phone: 408-565-4621 830 Email: rajiv@nortelnetworks.com 832 Babu Narayanan 833 Nortel Networks 834 2305 Mission College Blvd 835 Santa Clara, CA 95054, USA 836 Phone: 408-565-4537 837 Email: bon@nortelnetworks.com 839 Osama S. Aboul-Magd 840 Nortel Networks 841 P.O. Box 3511, Station C 842 Ottawa, Ontario, Canada 843 K1Y 4H7 844 Phone: 613-763-5827 845 Email: osama@nortelnetworks.com 847 Bilel Jamoussi 848 Nortel Networks 849 600 Technology Park Drive 850 Billerica, MA 01821, USA 851 Phone: 978-288-4506 852 Email: jamoussi@nortelnetworks.com 854 Sahay Expires January 2002 16 855 Raj Jain 856 Nayna Networks, Inc. 857 157 Topaz St 858 Milpitas, CA 95035, USA 859 Phone: 408-956-8000 Ext 309 860 Email: raj@nayna.com 862 Sudheer Dharanikota 863 Nayna Networks, Inc. 864 157 Topaz St 865 Milpitas, CA 95035, USA 866 Phone: 408-956-8000 Ext 357 867 Email: Sudheer@nayna.com 869 Riad Hartani 870 Caspian Networks 871 170 Bytech Drive 872 San Jose, CA 95134, USA 873 Phone: 408-382-5216 874 Email: riad@caspiannetworks.com 876 Sahay Expires January 2002 17 877 Full Copyright Statement 879 "Copyright (C) The Internet Society (date). All Rights Reserved. 880 This document and translations of it may be copied and furnished to 881 others, and derivative works that comment on or otherwise explain it 882 or assist in its implmentation may be prepared, copied, published 883 and distributed, in whole or in part, without restriction of any 884 kind, provided that the above copyright notice and this paragraph 885 are included on all such copies and derivative works. However, this 886 document itself may not be modified in any way, such as by removing 887 the copyright notice or references to the Internet Society or other 888 Internet organizations, except as needed for the purpose of 889 developing Internet standards in which case the procedures for 890 copyrights defined in the Internet Standards process must be 891 followed, or as required to translate it into 893 Sahay Expires January 2002 18