CCAMP WG V. Sahay Internet Draft R. Ramaswami Document: draft-sahay-ccamp-ntip-00.txt O. Aboul-Magd B. Jamoussi Nortel Networks R. Jain S. Dharanikota Nayna Networks R. Hartani Caspian Networks February 2001 Network Transport Interface Protocol (NTIP) for Photonic Cross Connects (PXC) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This draft describes the transport network interface protocol (NTIP) for photonic cross connects (PXC). NTIP is implemented between a PXC and transport network element (TNEs). NTIP is a protocol that uses TCP/IP for the transport of information related to defect notification, trace monitoring, adjacency discovery, and diagnostic messages between directly attached PXC and TNE. The use of TCP as the transport protocol ensures reliable and in-sequence delivery of NTIP messages. 2. Conventions used in this document Sahay Expires July 2001 1 Draft-sahay-ccamp-ntip-00.txt February 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction Fast restoration of failed light paths is critical for PXCs and it requires support for fast and accurate failure detection. Most PXCs do not look into the optical signals that flow through them. Some can detect presence or loss of light on a port. However presence of light does not necessarily mean that the light path is fine. For example when a link fails, generators between the point of failure and the PXC may inject an alarm indication signal (AIS) on a light signal. Unless the PXC decodes the framing of the light signal (possibly using some electrical circuitry), AIS will appear as presence of light. Also, some of the DWDM equipment (also called Transport Network Elements in this document) can control the switching ON and OFF of the AIS by configuration (or on demand). This feature can be leveraged to the advantage of the faster fault detection and hence the recovery times. Unlike the PXC, the transport network elements (TNE) attached to it are aware of their equipment failure as well as the quality and framing of the light paths passing through them. Failure information can be dynamically conveyed from the TNE to the PXC using out of band IP messaging. The transport network interface protocol (NTIP) defines the set of messages and the transport mechanism used for the exchange of failure conditions. NTIP is implemented between the PXC and the TNE. NTIP is an IP message handshake transported over an IP network. The implementation of NTIP between TNE and PXC achieves the following goals: - Defect Notification: NTIP is used by the TNE to relay failure conditions and precise link, fiber, and equipment status notification to PXC. Defect reporting can be both event-driven (e.g., link failures), polling-driven (e.g., regular link sanity checks) or time-driven (e.g., periodic). - Trace Monitoring: A PXC can use NTIP to request a TNE to monitor a certain pattern in the overhead of a light path. This capability could be used by PXC for validating light path identity. - Diagnostics: NTIP could be used by OXC to request a TNE to perform diagnostics on any port or channel. - Adjacency Discovery: NTIP could be used by both PXC and TNE to send and receive in band signals for automatic discovery of their optical connectivity. Sahay Informational-July 2001 2 Draft-sahay-ccamp-ntip-00.txt February 2001 The following assumptions about the solution make the requirements for such mechanisms clearer: - PXC and TNE can communicate on the configuration relationships of their views of the connections and their grouping. - PXC and TNE can negotiate on their individual feature support capabilities during registration phase. This draft is only concerned with NTIP aspects that are related to defect notification. Other features are added to the protocol in the future versions. 4. Reference Model The current generation of PXCs will interoperate with opaque line systems such as SONET regenerators, wavelength translators, etc. Eventually when enough transparent line systems are deployed, PXCs will interwork with them leading to an all optical network (AON). The need for NTIP exists in both cases. The following reference model focuses on interoperation of PXCs with opaque line systems. A reference model is shown in Figure 1. TNE are used to connect PXC ports to the transport system. TNE could be a set of OEO devices followed by a DWDM mux as shown in Figure 1. A TNE regenerates the signal coming from the PXC and might be capable of translating the wavelength. The key features of a TNE in the reference model are its ability to detect defects on its ports and to communicate defect information back to the PXC using NTIP. +---------+ TNE |\ /| TNE +---------+ | +---| +---+ | \ / | +---+ |---+ | | |Por|->| TX|->| \ / |<-| TX|<-|Por| | | | t| |---| | \ / | |---| | t| | | | |<-| RX|<-| \ / |->| RX|->| | | | +---| +---+ | \=====>/ | +---+ |---+ | | | | /<=====\ | | PXC | | PXC +---| +---+ | / \ | +---+ |---+ | | |Por|->| TX|->| / \ |<-| TX|<-|Por| | | | t| |---| | / \ | |---| | t| | | | |<-| RX|<-| / DWDM MUX \ |->| RX|->| | | | +---| +---+ |/ \| +---+ |---+ | |=========| |=========| |controlle| +===+ +===+ |controlle| | r |<>| | | |<>| r | +---------+^ +===+ +===+ ^+---------+ | TNE TNE | | controller controller | NTIP NTIP PXC = Photonic CrossConnect TNE = Transport Network Element Sahay Informational-July 2001 3 Draft-sahay-ccamp-ntip-00.txt February 2001 TX = Transmit RX = Receive FIGURE 1: PXC to TNE Reference Configuration Each PXC port consists of two unidirectional fibers, one for input (RX) and one for output (TX). Four TNE ports are associated with each PXC port (RX and TX). The TNE port that is connected to PXC is referred to as drop-side port, and the one that is connected to the line is called the line-side port. Figure 1 shows that a PXC will communicate with several TNEs. On the other hand, a TNE only communicates with a single PXC. A TNE can detect failures on signals it receives. Additionally some TNEs may be able to detect certain failures on their output ports such as laser failure. 5. NTIP Overview 5.1 Configuration Whenever automatic discovery is not available, a PXC is provisioned with information on how its ports are connected to TNE. It is also provisioned with the primary and the secondary IP addresses of each TNE connected to it. NTIP defines a set of configurable parameters such as protocol timers, retry counts, etc. Those parameters could be assigned default values or allowed to be set as needed or negotiated. 5.2 Registration As a TNE starts up, it registers with the PXC whose address is configured in it. A TNE registers by opening a TCP session with the PXC, and sending a registration request message. TNE registration allows PXC to create its internal context structure for this particular TNE. 5.3 Keep Alive NTIP utilizes keep alive messages. Keep alive messages are exchanged periodically between TNE and PXC to verify the sanity of the connection. The keep alive message interval is a configurable parameter. 5.4 Defect Monitoring Defect monitoring is initiated by the PXC by telling the TNE which ports to monitor for defects (signal degradation, loss of light, etc.). Defect monitoring will be initiated by the PXC after setting a light path through a TNE port. PXC terminates defect monitoring on a port before it disconnects the light path on that port. 5.5 Trace Monitoring Sahay Informational-July 2001 4 Draft-sahay-ccamp-ntip-00.txt February 2001 Trace monitoring ensures that a light path is connected to the correct client. A trace (light path Id) is injected by the client in the light path. After setting up a light path, PXC will request TNE to match the supplied trace id with that in the light path. The TNE informs the PXC in case of a mismatch. Trace Id is a pattern that can be injected and monitored in a light path without affecting its payload. A few different alternative ways of implementing it are possible. Trace Id may be injected in wrapper or as a pilot tone. NTIP supports all of them. The PXC discontinue the trace monitoring process for a particular light path before deleting it. 5.6 Status Request/Response Status request is initiated by the PXC and is triggered by an NTIP user application, e.g. NMS. Status response contains the status of the requested to TNE ports. It is sent by the TNE in response to status request. 5.7 Batching of Messages To reduce message traffic, TNE can pack several defect notification messages into a single message. Latency could be experienced as a result of batching since TNE has to hold off sending defects for an amount of time necessary to collect enough defects. 5.8 Resynchronization Resynchronization is needed every time an NTIP session restarts. An NTIP session could restart due to TCP connection failure, PXC restart due to internal reasons, e.g. control plan restart or PXC restart, TNE restart, or as a result of a deletion of the NTIP session due to time out. Each TNE keeps track of its NTIP session. If the session is deleted, it attempts to create another session over TCP/IP periodically. The time it waits before initiating a second attempt is a configurable parameter. Once TNE succeeds in creating a TCP connection with PXC, it repeats the registration procedure as mentioned in section 5.2. Upon receiving the registration request, the PXC goes into a resynchronization phase requesting an update on the port status of all TNE ports that it is interested in. The PXC confirms the end of the synchronization phase to the TNE when it receives the status of all the requested ports. Resynchronization helps the reporting of failure events that would have been missed by the PXC due to the NTIP session being down. It Sahay Informational-July 2001 5 Draft-sahay-ccamp-ntip-00.txt February 2001 also allows the TNE not to remember the defects monitoring commands given before resynchronization. 5.9 TNE to PXC Transport A single high availability router/switch is recommended for connecting TNE to PXC. This transport arrangement is referred to as NTIP transport network. TNE defect messages are required to reach the PXC with little delays. It is recommended that the NTIP network supports the priority handling of packets, e.g. differentiated services. Messages related to defect reporting are transported with high priority. All other messages, that are not time critical, are transported using a lower priority. NTIP messages are transported reliably using TCP as the transport protocol. The use of TCP also ensures in-sequence delivery of NTIP messages, hence relieving the protocol developer from creating an additional layer for reliable delivery. Figure 2 shows the logical connectivity between PXC and TNE. +-----+ +-----+ | | +-------------+ +----+ | | | | |-------+----+ |--+ | PXC |---| IP Network |-------| |-+ | | | | +----+ | | +-------------+ TNEs +-----+ |<---------------------------->| TCP Session FIGURE 2: PXC-TNE Logical Connectivity Figure 2 emphasizes the fact that a PXC communicates with several TNEs while a TNE only communicates with a single PXC. 5.10 Defect Types A TNE will report the following defects to PXC. - Signal Degrade (SD): TNE reports this type of failure when the light signal on one of its ports degrades below a configured threshold. - Signal Fails (SF): TNE reports SF to PXC when the incoming signal fails on one of its ports. - AIS: TNE reports AIS to PXC when it detects AIS-LINE on one of its ports. - Trace Mismatch: TNE reports Trace Mismatch when it mismatch is detected by one of its ports between an injected pattern and the expected pattern. Sahay Informational-July 2001 6 Draft-sahay-ccamp-ntip-00.txt February 2001 - Equipment Failure: TNE will notify PXC of equipment failure (e.g. OEO card or laser failure on the transport side) and the port number that suffered the failure. 6.0 NTIP Messages and Procedures All NTIP messages start with the following two fields: NTIP Vers: 2-byte field that contains the NTIP protocol version number. Type: 2-byte field that contains the message type The version number provides the features supported by the other side of the NTIP communication. It is only verified at the establishment of NTIP session, and is used during registration and resynchronization states. 6.1 Registration Message The format of the Registration Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + TNE Model Number + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = REG-REQ TNE Model Number: 16-byte filed that specifies the TNE model number Procedure: Registration Message is sent by the TNE to the PXC at start up. If a PXC receives a Registration Message with a different NTIP Vers than expected it may take one of the following actions: - Reject the registration request - Reject the registration request if the received NTIP Vers differs by more than an allowed difference. If the difference is Sahay Informational-July 2001 7 Draft-sahay-ccamp-ntip-00.txt February 2001 acceptable, then the message set common to the two versions will be supported. 6.2 Registration Complete Message The format of the Registration Complete Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = REG-COMPLETE Procedure: The Registration Complete Message is sent by PXC to TNE indicating a successful completion of the registration. The message is sent only during the initial synchronization phase. 6.3 KeepAlive Message The format of the KeepAlive Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = KEEP-ALIVE-REQ Procedure: The KeepAlive Message is sent by the TNE to PXC every T-keep-alive- interval seconds (the default is 60 seconds). If PXC does not receive a KeepAlive Message every T-keep-alive-timeout (t-keep-alive-timeout = 3*T-keep-alive-interval), it takes down the NTIP session. 6.4 KeepAlive Response Message The format of the KeepAlive Response Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = KEEP-ALIVE_RES Sahay Informational-July 2001 8 Draft-sahay-ccamp-ntip-00.txt February 2001 Procedure: The KeepAlive Response Message is sent by PXC to TNE in response to a KeepAlive Message. 6.5 Monitor Request Message The format of the Monitor Request Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Ports | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AR |DM | TType |MT | Tr Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Trace ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AR |DM | TType |MT | Tr Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Trace ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = MON-REQ No. of Ports: 2-byte field that contains the number of ports reported in this message. Port Address: 4-byte field that is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | shelf | slot | Sub Slot | port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sahay Informational-July 2001 9 Draft-sahay-ccamp-ntip-00.txt February 2001 Alarm Reporting, AR: 2-bit field that indicates start, stop, or no change to alarm reporting. Defect Monitoring, DM: 2-bit field that indicates start, stop, or no change to failure monitoring. Trace Type, TType: 4-bit used to indicate the trace type. Possible types are, pilot tone, wrapper, J0 bytes. Monitor of Trace, MT: 2-bit field that indicates start, stop, or no change to trace monitoring Trace Length, Tr Len: 6-bit field that indicates the length of the monitored trace. Trace ID: Up to 63 bytes. It defines the trace to be monitored. User could treat the Trace ID as ASCII or binary Procedure: The Monitor Request Message is sent by PXC to TNE. After setting a light path through TNE, PXC will send Monitor Request Message indicating the start of defect monitoring and the list of monitored ports. Before disconnecting a light path, PXC sends Monitor Request Message with DM set to stop indicating the end of the defect monitoring process. The Monitor Request Message is also used for the start and the stop of alarm reporting and trace monitoring. Upon the start of trace monitoring, the PXC supplies the Trace ID to be compared to that in the light path (say, in SONET J0 bytes, or in wrapper, or pilot tone). Trace ID is not included in the Monitor Request Message when MT is set to stop or no change. 6.6 Defect Notification The format for the Defect Notification Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Ports | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sahay Informational-July 2001 10 Draft-sahay-ccamp-ntip-00.txt February 2001 | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FS | FT | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FS | FT | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = DEFECT-NOTIFICATION Failure Status, FS: 2-bit field that indicates fail or clear. Failure Type, FT: 1-byte filed that indicates the failure (defect) type as discussed in section 5.10. Procedure: The Defect Notification Message is sent by the TNE in response to a PXC Monitor Request Message. The Defect Notification Message is sent with the highest possible priority to reach the destination PXC in a timely fashion. 6.7 Status Request Message The format of the Status Request Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Ports | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sahay Informational-July 2001 11 Draft-sahay-ccamp-ntip-00.txt February 2001 | Tag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (why Tag length is two bytes, page 26????) Type: Type = STATUS-REQ Tag: A 4-bit field that is used for message identification Procedure: The Status Request Message is sent by PXC to TNE to solicit the status of some or all of the TNE ports. Status Request Message could also be sent to query the status of a previously issued Monitor Request Message. 6.8 Status Response Message The format of the Status Response Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Ports | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | CStat | Dyn Stat | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | CStat | Dyn Stat | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = STATUS-RESP Configuration Status, CStat: 4-bit field that indicates the provisioned state of a TNE port. It indicates whether the port is enabled or disabled. Dynamic State, Dyn Stat: Sahay Informational-July 2001 12 Draft-sahay-ccamp-ntip-00.txt February 2001 1-byte field that indicates the failure type experience by a TNE port. Procedure: The Status Response Message is sent from TNE to PXC. A TNE sends a Status Response Message in response to a Status Request Message. For each port requested, the Status Response Message includes a configuration status (enabled or disabled), and a dynamic port defect status that specify the failure type as discussed in section 5.10. 6.9 Configuration Update The format of the Configuration Update Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTIP Vers | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No. of Ports | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CStat | Dyn Stat | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CStat | Dyn Stat | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Type = CONFIG-UPDATE Procedure: The Configuration Update Message is sent unsolicited by TNE to PXC. It is used for dynamically modifying the configuration while in operation. 7. Security Considerations This draft does not introduce any new security issues. 8. References Sahay Informational-July 2001 13 Draft-sahay-ccamp-ntip-00.txt February 2001 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 9. Author's Addresses Vasant Sahay Nortel Networks 2305 Mission College Blvd Santa Clara, CA 95054, USA Phone: 408-565-4601 E.mail: vasants@nortelnetworks.com Rajiv Ramaswami Nortel Networks 2305 Mission College Blvd Santa Clara, CA 95054, USA Phone: 408-565-4621 Email: rajiv@nortelnetworks.com Osama S. Aboul-Magd Nortel Networks P.O. Box 3511, Station C Ottawa, Ontario, Canada K1Y 4H7 Phone: 613-763-5827 Email: osama@nortelnetworks.com Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA Phone: 978-288-4506 Email: jamoussi@nortelnetworks.com Raj Jain Nayna Networks, Inc. 157 Topaz St Milpitas, CA 95035, USA Phone: 408-956-8000 Ext 309 Email: raj@nayna.com Sudheer Dharanikota Nayna Networks, Inc. Sahay Informational-July 2001 14 Draft-sahay-ccamp-ntip-00.txt February 2001 157 Topaz St Milpitas, CA 95035, USA Phone: 408-956-8000 Ext 357 Email: Sudheer@nayna.com Riad Hartani Caspian Networks 170 Bytech Drive San Jose, CA 95134, USA Phone: 408-382-5216 Email: riad@caspiannetworks.com Sahay Informational-July 2001 15 Draft-sahay-ccamp-ntip-00.txt February 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Sahay Informational-July 2001 16