CCAMP Working Group Michiel van Everdingen Internet Draft (Lucent Technologies) Expiration Date: December 2002 Greg Bernstein (Ciena Corporation) June 2002 Link Management Protocol Update draft-everdingen-ccamp-lmp-update-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. Abstract Optical networks are being developed to include photonic switches, optical crossconnects, SONET/SDH crossconnects and routers. These networks consist of data links and a logically separated control network. Furthermore, multiple data links may be combined to form a single traffic engineering (TE) link for routing purposes. This draft proposes an update of the Link Management Protocol LMP. LMP runs between neighboring nodes (regarding data links) and is used to manage TE links. Specifically, LMP can be used to discover and verify the physical connectivity of the data links, correlate the data link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in GMPLS switched networks. Everdingen et al [Page 1] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Table of Contents 1. Introduction..................................................3 2. LMP Overview..................................................6 3. Neighbor Discovery............................................8 4. Link Property Correlation....................................12 5. Verifying Data Link Connectivity.............................14 5.1. Example of Link Connectivity Verification................16 6. Fault Management.............................................18 6.1. Fault Detection..........................................19 6.2. Fault Localization Procedure.............................19 6.3. Examples of Fault Localization...........................19 7. Addressing...................................................23 8. LMP Authentication...........................................23 9. IANA Considerations..........................................23 10. LMP Finite State Machines....................................24 10.1. TE Link FSM.............................................24 10.2. Data Link FSM...........................................25 11. LMP Message Formats..........................................29 11.1. Common Header...........................................29 11.2. LMP Object Format.......................................30 11.3. Authentication..........................................31 11.4. Link Verification.......................................33 11.5. Link Summary Messages...................................36 11.6. Fault Management Messages...............................37 12. LMP Object Definitions.......................................39 12.1. NODE_ID Classes.........................................39 12.2. LINK _ID Classes........................................40 12.3. INTERFACE_ID Classes....................................41 12.4. MESSAGE_ID Class........................................41 12.5. MESSAGE_ID_ACK Class....................................42 12.6. BEGIN_VERIFY Class......................................42 12.7. BEGIN_VERIFY_ACK Class..................................43 12.8. VERIFY_ID Class.........................................43 12.9. TE_LINK Class...........................................43 12.10. DATA_LINK Class........................................44 12.11. CHANNEL_STATUS Class...................................48 12.12. CHANNEL_STATUS_REQUEST Class...........................49 12.13. ERROR_CODE Class.......................................49 13. Security Considerations......................................51 14. References...................................................51 15. Authors' Addresses...........................................52 Everdingen et al [Page 2] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Changes compared to [LMP] - Removed the concept "control channel". - Removed possibility of (UDP over HDLC encoded) test messages to be directly sent on DCC channels, bypassing the DCN network - Included optional procedure for neighbor discovery. - Made clear that LMP's fault management procedure implements a tandem connection monitoring function. - Several editorial changes (a.o. in abstract and introduction) 1. Introduction Optical network elements can use a common control plane like GMPLS to dynamically allocate resources and to provide network survivability using protection and restoration techniques. These optical network elements form together an optical network. Optical networks consist of several layer networks. The main layers are: - OC-N / STM-N: a layer consisting of OC-N/SMN-N data links - STS-N / HO-VC: a layer consisting of STS-N/HO-VC data links - VT-1.5 / LO-VC: a layer consisting of VT-1.5/LO-VC data links As seen from a single layer network, three functions are of interest: - Optical Switching (OXC) - Optical Multiplexing (MUX) - Optical Termination (TRM). From an OC-N, STM-n perspective: - Optical Line Systems (OLS) contain the MUX function: these systems multiplex OC-n/STM-n signals into a DWDM signal. - Fully transparent optical cross connects contain the OXC function. - SONET/SDH ADMs and IP Routers contain the TRM function. From an HO-VC, STS-N perspective: - Optical Line Systems (OLS) are not visible. - Fully transparent optical cross connects are not visible. - SONET/SDH ADMs contain the OXC, MUX and TRM functions. - IP Routers contain the TRM function. In the remainder of this document, we will refer to these optical functions (OXC, MUX and TRM) as 'nodes'. LMP can be used for any type of optical network element, regardless if the network combines an OXC and a MUX function or not. A pair of nodes (e.g., two OXCs) may be connected by thousands of fibers. In this document, these fibers are more generally called data links. Note that these data links may be multiplexed together in multiplexing systems. Furthermore, independently of this multiplexing, multiple data links may be combined into a single traffic-engineering (TE) link for routing purposes. Everdingen et al [Page 3] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 To enable communication between nodes for routing, signaling, and link management, a control network must be present that connects every pair of nodes that are neighbors regarding data links. This draft specifies an update of the link management protocol [LMP]. LMP runs between neighboring nodes (neighboring regarding the data links) and is used to manage TE links; see Figure 1. +------+ +------+ +------+ +------+ | | ----- | | ----- | | ----- | | | TRM1 | ----- | OXC1 | ----- | OXC2 | ----- | TRM2 | | | ----- | | ----- | | ----- | | +------+ +------+ +------+ +------+ ^ ^ ^ ^ ^ ^ | | | | | | +----LMP---+ +----LMP----+ +---LMP-----+ Figure 1: LMP Model Note that LMP runs between nodes that are either - Terminating the data link (TRM1 and TRM2) or - Cross connecting the data link (OXC1 and OXC2). Note furthermore that LMP does not consider multiplexing nodes that multiplex the data link (see Figure 2). A companying draft [LMP- DWDM] specifies the protocol to be used between OXC and MUX. +------+ +------+ +------+ +------+ | | ----- | | | | ----- | | | OXC1 | ----- | MUX1 | ===== | MUX2 | ----- | OXC2 | | | ----- | | | | ----- | | +------+ +------+ +------+ +------+ ^ ^ | | +----------------------LMP----------------------+ Figure 2: LMP and Multiplexing nodes In GMPLS, the control network between two neighboring nodes is no longer required to use the same physical medium as the data links between those nodes. For example, a control network could use separate wavelengths, fibers or Ethernet links and may contain IP routers that are not involved in any operation on the data links. A consequence of allowing the control network to be physically diverse from the associated data links is that the health of this control network does not necessarily correlate to the health of the data links, and vice-versa. Therefore, a clean separation between the fate of the control network and data links must be made. Everdingen et al [Page 4] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Each of the two end-points of a data link will be either a TTP or a CTP, depending on its multiplexing capability. A TTP, which resides in a TRM node, terminates the data link. A CTP, which resides in an OXC node, transparently cross connects the signal on the data link. The distinction between TTP and CTP is important since the management of the data-bearing links (including, for example, discovery and verification) is different based on the type of end-points connected. For example, a SONET crossconnect is a TTP for an OC-192 data link. This implies that, for this data link, the SONET crossconnect will always send out the same access point identifier in the in-band J0 signal. In contrast, a photonic cross connect, which is a CTP for an OC-192 data link, may use the in-band J0 signal as a kind of "test- signal". If data links are grouped together into a single TE link using link bundling [BUNDLE], then the link resources must be identified using two levels: TE link Id, and interface Id (an Id of the data link within the TE link). Resource allocation happens at the lowest level (the data links). LMP is designed to support aggregation of one or more data-bearing links into a TE link (either ports into TE links, or component links into TE links). The purpose of forming a TE link is to group/map the information about certain physical resources (and their properties) into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. Everdingen et al [Page 5] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 2. LMP Overview The core procedure of LMP is link property correlation. Link property correlation is used to synchronize the TE link properties and verify configuration. An "LMP adjacency" is present between two nodes that are neighbors regarding a data link. LMP provides an optional procedure to automatically discover the connectivity of the data links, but this connectivity can also be manually provisioned. The link property correlation function of LMP is designed to aggregate multiple data links into a TE link and to synchronize the properties of the TE link. As part of the link property correlation function, a LinkSummary message exchange is defined. The LinkSummary message includes the local and remote TE Link Ids, a list of all data links that comprise the TE link, and various link properties. A LinkSummaryAck or LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummary message indicating agreement or disagreement on the link properties. In this draft, two additional LMP procedures are defined: link connectivity verification and fault management. Link connectivity verification is used to verify the continued physical connectivity of the data links between the nodes. The link verification procedure uses a test signal that is sent over the data links and TestStatus messages that are transmitted back over the control network. Fault management is used to localize a fault to a specific data link. By means of this procedure, an OXC or TRM node can detect if an incoming signal fault is caused by a fault on the incoming data link or is caused by a fault further in the upstream direction. The LMP fault management procedure is based on a ChannelStatus exchange using the following messages: ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. The ChannelStatus message is sent unsolicitated and is used to notify an LMP neighbor about the status of one or more data links of a TE link. The ChannelStatusAck message is used to acknowledge the receipt of the ChannelStatus message. The ChannelStatusRequest message is used to query an LMP neighbor for the status of one or more data channels of a TE Link. The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest message and indicate the states of the queried data links. All LMP messages are UDP encoded. This implies that the control network must provide a UDP service. LMP messages are transmitted reliably over the control network using Message Ids and retransmissions. Message Ids are carried in MESSAGE_ID objects. No more than one MESSAGE_ID object may be included in an LMP message. The Message Id is always within the Everdingen et al [Page 6] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 scope of the LMP adjacency. The value of the Message Id is monotonically increasing and only decreases when the value wraps. In addition to these UDP based LMP messages, LMP uses the in-band "access point identifier" for neighbor discovery and link verification. The organization of the remainder of this document is as follows. In Section 3, a method is presented to discover the connectivity of the data links. In Section 4, the link property correlation function using the LinkSummary message exchange is described. The link verification procedure is discussed in Section 5. In Section 6, it is shown how LMP can be used to isolate TE link and data link failures within the optical network. Sections 7, 8 and 9 describe the usage of message identifiers, graceful restart and addressing respectively. Several finite state machines (FSMs) are given in Section 12. The message formats and object definitions are defined in Section 13 and 14 respectively. Everdingen et al [Page 7] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 3. Neighbor Discovery In this section, an optional LMP procedure is described to automatically detect the identification of the other end of a data link in the upstream direction. In other words the neighbor discovery procedure automatically detects the association . The neighboring node in the upstream direction is informed of this association by means of the subsequent link correlation procedure. The optional neighbor discovery as described in this section uses the capability of optical systems to carry an in-band "access point identifier" [G707]. Alternative discovery procedures that do not require the usage of this access point identifier are described in [OIF-UNI] and in [NDP-PPP]. These procedures use the line or section DCC (data communications channel) and are especially useful in case the access point identifier is not available for use, i.e., prohibited by the carrier, or in accessible by the equipment. These alternative discovery procedures are applicable in case the data link is an STM-N, OC-N and STS-1/3/.../VC-3/4/...; they are not applicable in case the data link is an VT-1.5, VC-11 or VC-12 data link. Basically, automatic neighbor discovery as described in this section is implemented by reading the incoming access point identifier. A Sub-Network Point (TTP or CTP) that implements the automatic neighbor discovery procedure MUST send its identification in the access point identifier in a signal present on the data link. In case the Sub-Network Point is a TTP, the access point identifier is sent continuously. In case the Sub-Network Point is a CTP, the access point identifier is sent in any test signal, e.g. the supervisory unequipped signal (see [G707] and [G783]). The access point identifier is encoded in a specific byte in the data link according to the table below: Data link type Access point identifier to be used -------------- ---------------------------------- STM-N, OC-N J0 STS-1/3/.../VC-3/4/... J1 VT-1.5/VC-11/12 J2 In case an IPv4 control network is used, the identification SHOULD be formatted into 16 bytes as follows ([OIF 2000.159.01]): +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |CRC|Typ|Dis| Node Identifier | I'face Identifier | +---+---+---+-------------------------------+-------------------+ Everdingen et al [Page 8] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Figure 3: format of the access point identifier to enable automatic neighbor discovery The format as specified in Figure 3 is in line with the specification in [G707]. This SDH standard places the most stringent constraints on the contents of the access point identifiers. A Sub-Network Point (TTP or CTP) MAY also use an alternative format for the access point identifier, e.g. the one specified in G.831, Appendix I. In this case, discovery of the address of the sending access point will need involvement of a 'name server'. In case an IPv6 control network is used, the neighbor discovery scheme MUST follow this approach. According to [G707], all entries in the access point identifier in the are are formatted printable 7 bit encoded ASCII characters (except for the CRC field). In case the access point identifier is formatted according to Figure 3, the fields have the following interpretation: CRC The CRC-7 code of the previous frame as specified in G.707. Typ The "type indicator" informs the receiver of the sender's role. Values are: "T": Trail Termination Point "C": Connection Termination Point Dis The "distinguishing identifier" avoids the proposed format to be confused with some other optional format, e.g. the format specified in G.831, Appendix I. Value: "@" Node Identifier The "node identifier" is the IPv4 address that identifies the sending Node_Id. The IPv4 address is encoded in 8 hex characters. I'face Identifier The "Interface Identifier" identifies the sender's Interface_Id in hex format. This gives port numbers 0-FFFFF (1,048,575) which should be enough for all types of Network Elements. As an example, a node with IP address 192.168.2.23 would sent out the following access point identifier (excluding the CRC) from a TTP with local interface id 421: T@C0A80217001A5 Everdingen et al [Page 9] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 A sending TTP that implements the automatic neighbor discovery scheme will continuously send out its own identification. This is according to [G831], "the access point identifier should not change while the access point remains in existence". A sending CTP that implements the automatic neighbor discovery scheme MUST send its identification as long as it has not received a linkSummary message indicating that the associated receiver has discovered this sending CTP. The CTP MAY send its identification continuously, until it is discovered. The CTP MAY also send its identification in intervals, until it is discovered. Example: Figure 4 shows 4 nodes and a single data link between these nodes. Two nodes terminate the data link on interfaces marked with 'T' (TTP). Two other nodes are transparent to the data link on interfaces marked with 'C' (CTP). Note that neighbor discovery is defined per datalink, so the actual number of datalinks per NE is not relevant. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | | B | | C | | | | | | | | | | | TRM1 | | OXC1 | | OXC2 | | TRM2 | +------+ +------+ +------+ +------+ Figure 4: automatic discovery example - 1 OXC1 should, when it wants to discover data link B, connect a test- set that sends an access point identifier to identify the sending connection point C in OXC1. This test-signal should be send long enough for OXC2 to detect and read the test-signal. OXC2 will continuously scan all its not discovered input ports for a discovery signal. At some point, OXC2 will detect the test-signal on data link B. See Figure 5. +------+ +------+ +------+ +------+ | T-|--->--|-C C-|--->--|-C C-|--->--|-T | | | A | / | B | \ | C | | | | | T | | T | | | | TRM1 | | OXC1 | | OXC2 | | TRM2 | +------+ +------+ +------+ +------+ Figure 5: automatic discovery example - 2 When OXC2 has read the access point identifier in the test signal, data link B is discovered. Subsequent link property correlation can then be invoked. Everdingen et al [Page 10] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Discovery of data link A is similar, except that the access point identifier is continuously sent. Discovery of data link C is also similar, except that the access point identifier is continuously monitored. In other words, there is no need for a sending respectively monitoring 'test-set' in TRM1 and TRM2. Everdingen et al [Page 11] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 4. Link Property Correlation As part of LMP, a link property correlation exchange is defined for TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N flag in the Object header). Negotiable objects can be used to let both sides agree on certain link parameters. Non-negotiable objects are used for announcement of specific values that do not need, or do not allow, negotiation. Each TE link has an identifier (Link_Id) that is assigned at each end of the link. The TE-link is only considered to be 'up' in case a linkSummaryAck message is received that indicates that the neighboring node agreed on the current TE-link configuration. See also section 12.1. Next to this usage for the initial agreement on the TE-link configuration, link property correlation MAY be done at any time a link is 'up'. The LinkSummary message is used to verify the consistency of the TE- link and containing data links on both sides. I.e. Link Summary messages are used to - Check bi-directional connectivity of the data links - Exchange and correlate data link parameters - Exchange and correlate TE link parameters - Agree on the aggregation of multiple data links into one TE link The LinkSummary message includes a TE_LINK object followed by one or more DATA_LINK objects. The TE_LINK object identifies the TE link's local and remote Link Id and indicates support for fault management and link verification procedures for that TE link. The DATA_LINK objects are used to characterize the data links that comprise the TE link. These objects include the local and remote Interface Ids, and may include one or more subobjects further describing the properties of the data links. If the LinkSummary message is received from a remote node and the Interface Id mappings match those that are stored locally, then the two nodes have agreement on the verification procedure (see Section 5) and the configuration of the data links. If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration. The LinkSummaryAck message is used to signal agreement on the Interface Id mappings and link property definitions. Otherwise, a LinkSummaryNack message MUST be transmitted, indicating which Interface mappings are not correct and/or which link properties are not accepted. Everdingen et al [Page 12] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 If a LinkSummaryNack message indicates that the Interface Id mappings are not correct and the link verification procedure is enabled, the link verification process SHOULD be repeated for all mismatched free data links. If a LinkSummaryNack message includes negotiable parameters, then acceptable values for those parameters MUST be included. If a LinkSummaryNack message is received and includes negotiable parameters, then the initiator of the LinkSummary message SHOULD send a new LinkSummary message. The new LinkSummary message SHOULD include new values for the negotiable parameters. These values SHOULD take into account the acceptable values received in the LinkSummaryNack message. Everdingen et al [Page 13] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 5. Verifying Data Link Connectivity In this section, an optional procedure is described that may be used to verify the physical connectivity of the data-bearing links. The procedure SHOULD be done any time there is uncertainty about the continued connectivity of the data-bearing links, e.g. after a data link failure. The procedure MAY be done on a periodic basis for all unallocated (free) data links of the TE link. Note that verification of the data links is only done after the data links have been discovered and correlated. The discovery procedure as described in this section uses the in-band access point identifier. Because the discovery procedure uses the access point identifier, it is only applicable for CTP-->--CTP and CTP-->--TTP data links. The verify procedure is not applicable for TTP-->--CTP and TTP-->--TTP data links: TTPs constantly send out their identification in-band. In other words, a TRM node does not need to explicitly send a "beginVerify" message to its LMP adjacency as this neighboring node can at any time verify the connectivity of the data link (by reading the access point identifier). Other verification procedures may be negotiated as part of the link property correlation. Specific flags in the TE_Link object can be used for this purpose. At the moment, only a flag value is defined for the verification method as described in this section. If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code = 1, "Link Verification Procedure not supported for this TE Link". If a BeginVerifyAck message is received, the local (transmitting) node sends the an in-band test signal over the corresponding data link(s). The only relevant information in this test signal is the access point identifier. This access point identifier is formatted according to format of the discovery message (see Figure 3). A characteristic of CTPs (points at an OXC node) is that the data links are transparent when allocated to user traffic. This characteristic poses a challenge for validating the connectivity of the data links. Therefore, to ensure proper verification of data link connectivity, it is required that a test-set is available to send and receive an in-band test signal at times the data link is not allocated for use traffic. In other words, the test-set must be able to terminate the test signal. The local (transmitting) node sends the test signal on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control network from the remote (receiving) node or (2) a timeout occurs. The remote node will send a given TestStatus message periodically over the Everdingen et al [Page 14] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 control network until it receives either a correlating TestStatusAck message or an EndVerify message is received over the control network. There is no requirement that all data links be terminated simultaneously, but at a minimum, the network element MUST be able to terminate the data links one at a time. For link verification, a TE link MUST include at least one data link. Furthermore, link verification will only succeed if the neighbors regarding the data link have connectivity over the control plane. To initiate the link verification procedure, the local node MUST send a BeginVerify message over the control network. To limit the scope of Link Verification to a particular TE Link, the LOCAL_LINK_ID MUST be non-zero. Furthermore, the BeginVerify message contains the number of data links that are to be verified. If the remote node receives a BeginVerify message and it is ready to process Test messages, it MUST send a BeginVerifyAck message back to the local node. When the local node receives a BeginVerifyAck message from the remote node, it SHOULD begin testing the data links by transmitting a test signal over each data link. The remote node MUST send either a TestStatusSuccess or a TestStatusFailure message in response for each data link. A TestStatusAck message MUST be sent to confirm receipt of the TestStatusSuccess and TestStatusFailure messages. It is also permissible for the sender to terminate the Test procedure anytime after sending the BeginVerify message. An EndVerify message SHOULD be sent for this purpose. Message correlation is done using message identifiers. This enables verification of data links, belonging to different link bundles or LMP sessions, in parallel. When the test signal is received, the received Interface Id is recorded and mapped to the local Interface Id for that data link, and a TestStatusSuccess message MUST be sent. The TestStatusSuccess message includes the local Interface Id and the remote Interface Id (received in the Test message). The receipt of a TestStatusSuccess message indicates that the test signal was detected at the remote node and the connectivity of the data link has been verified. When the TestStatusSuccess message is received, the local node SHOULD mark the data link as UP and send a TestStatusAck message to the remote node. If, however, the Test signal is not detected at the remote node within an observation period (specified by the VerifyDeadInterval), the remote node will send a TestStatusFailure message over the control network indicating that the verification of the physical connectivity of the data link has failed. When the local node receives a TestStatusFailure message, it SHOULD mark the data link as FAILED and send a TestStatusAck message to the remote node. When all the data links on the list have been tested, the Everdingen et al [Page 15] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 local node SHOULD send an EndVerify message to indicate that testing is complete on this link. If the local/remote data link mappings are known, then the link verification procedure can be optimized by testing the data links in a defined order known to both nodes. The suggested criteria for this ordering is in increasing value of the Remote_Interface_ID. Both the local and remote nodes SHOULD maintain the complete list of Interface Id mappings for correlation purposes. 5.1. Example of Link Connectivity Verification Figure 6 shows an example of the link verification scenario that is executed when the connectivity of all data links between OXC A and OXC B is to be verified. In this example, the TE link consists of three free CTPs. Furthermore OXC A and OXC B can communicate over a control network (indicated by a "c"). The verification process is as follows: OXC A sends a BeginVerify message over the control network "c" to OXC B indicating it will begin verifying the ports. OXC B receives the BeginVerify message and returns the BeginVerifyAck message over the control network to OXC A. When OXC A receives the BeginVerifyAck message, it begins transmitting the test signal over the first CTP (Interface Id=1). When OXC B receives the test signal, it maps the received Interface Id to its own local Interface Id = 10 and transmits a TestStatusSuccess message over the control network back to OXC A. The TestStatusSuccess message includes both the local and received Interface Ids for the port. OXC A will send a TestStatusAck message over the control network back to OXC B indicating it received the TestStatusSuccess message. The process is repeated until all of the data links are verified. At this point, OXC A will send an EndVerify message over the control network to OXC B to indicate that testing is complete; OXC B will respond by sending an EndVerifyAck message over the control network back to OXC A. c -----+----------------------------------+------ | | +-----------+ +-----------+ | OXC A | | OXC B | | 1-+--------------------->+-10 | | | | | | 2-+ /---->+-11 | | | /---------/ | | | 3-+----/ +-12 | | | | | | 4-+--------------------->+-14 | | | | | +-----------+ +-----------+ Everdingen et al [Page 16] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Figure 6: Example of link verification between OXC A and OXC B. Everdingen et al [Page 17] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 6. Fault Management In this section, an optional LMP procedure is described that is used to manage failures by rapid notification of the status of one or more data links of a TE Link. The scope of this procedure is within a TE link, and as such, the use of this procedure is negotiated as part of the LinkSummary exchange. The procedure can be used to rapidly isolate link failures and is designed to work for both unidirectional and bi-directional data links. The fault management procedure for a specific data link is especially useful in two cases: 1. The OXC node does not get fault information from the MUX node. 2. The OXC node can't use fault information from the MUX node An example for case (1) is when the OXC node and the MUX node are separate network elements and no communication, like e.g. LMP-DWDM, is available between these nodes. An example for case (2) is if the data link is actually a serial compound data link. In the latter case, LMP's fault management function provides a kind of tandem connection monitoring function. LMP implements this tandem connection monitoring by sending the state of the signal at the egress node of the serial compound data link to the ingress node of the serial compound data link. The ingress node then compares this information with it's own information regarding the state of the signal. The difference between the state of the signal at the egress node and the ingress node gives information about the serial compound data link. +------+ +------+ +------+ +------+ | C-|--->--|-C--C-|--->--|-C--C-|--->--|-C | | | A | | B | | C | | | | | | | | | | | OXC1 | | OXC2 | | OXC3 | | OXC4 | +------+ +------+ +------+ +------+ Figure 7: serial compound data link Figure 7 shows an example of a serial compound data link. OXC2 and OXC3 do not implement LMP nor GMPLS. They are simply fixed through cross-connects for this data link. In this case, OXC4 can't find out if the data link between OXC1 and OXC4 is failed from MUX nodes that might be present between OXC3 and OXC4. The only way OXC4 can know that the data link between OXC1 and OXC4 is failed is by comparing the fault state of the signal incoming at OXC4 and the fault state of the signal outgoing from OXC1. In other words, fault management provides a way to find out if this data link is failed on any of the sections A, B or C. Everdingen et al [Page 18] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 6.1. Fault Detection Fault detection determines that there is a failure in the received signal on a data link. How fault detection is done is outside the scope of LMP. 6.2. Fault Localization Procedure LMP provides a failure notification through the ChannelStatus message. This message may be used to indicate that a single data link has failed, multiple data links have failed, or an entire TE link has failed. Failure correlation is done locally at each node upon receipt of the failure notification. To localize a fault to a particular data link between neighboring OXCs, a downstream node (downstream in terms of data flow) that detects data link failures will send a ChannelStatus message to its upstream neighbor indicating that a failure has occurred (bundling together the notification of all of the failed data links). An upstream node that receives the ChannelStatus message MUST send a ChannelStatusAck message to the downstream node indicating it has received the ChannelStatus message. The upstream node should correlate the failure to see if the failure is also detected locally for the corresponding data link(s). If, for example, the failure is clear on the input of the upstream node or internally, then the upstream node will have localized the failure. After this correlation process, the upstream node MUST send a ChannelStatus message to the downstream node indicating that the data link is failed or is ok. The upstream node MUST repeat this ChannelStatus message until it receives a corresponding ChannelStatusAck message. Once the failure has been localized, GMPLS signaling protocols can be used to initiate span or path protection/restoration procedures. If all of the data links of a TE link have failed, then the upstream node MAY be notified of the TE link failure without specifying each data link of the failed TE link. This is done by sending failure notification in a ChannelStatus message identifying the TE Link without including the Interface Ids in the CHANNEL_STATUS object. 6.3. Examples of Fault Localization In Figure 8, a sample network is shown where four OXCs are connected in a linear array configuration. The control network is indicated by a line labeled with a "c". The data links are bi-directional. Figure 8 shows two types of data link failures (indicated by ## in the figure): (A) a data link corresponding to the downstream direction of a bi- directional LSP fails, Everdingen et al [Page 19] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 (B) two data links corresponding to both directions of a bi- directional LSP fail. In the first example [see Figure 8(a)], there is a failure on one direction of the bi-directional LSP. OXC 4 will detect the failure and will send a ChannelStatus message to OXC3 indicating the failure to the corresponding upstream node. When OXC3 receives the ChannelStatus message from OXC4, it returns a ChannelStatusAck message back to OXC4 and correlates the failure locally. OXC3 determines that the signal it sends on the data link to OXC4 is free of failure. Correlation of this information with the information received from OXC4 learns that the failure is located on the data link between OXC3 and OXC4. OXC3 will subsequently send a ChannelStatus message to OXC4 to inform OXC4 of the failure on the data link between OXC3 and OXC4. In the second example [see Figure 8(b)], a single failure (e.g., fiber cut) affects both directions of the bi-directional data link. OXC3 (OXC2) will detect the failure of the downstream direction and send a ChannelStatus message to the upstream node OXC2 (OXC3) indicating the failure. Upon reception of the ChannelStatus message, OXC2 (OXC3) will send a ChannelStatusAck message to OXC3 (OXC2). Consequently, both OXC2 and OXC3 have localized the failure in both directions of the data link. c --+----------------+----------------+----------------+-- | | | | +-------+ +-------+ +-------+ +-------+ | OXC 1 | | OXC 2 | | OXC 3 | | OXC 4 | | | | | | | | | ----+---\ | | | | | | | <---+---\\--+--------+-------+---\ | | | /--+---> | \--+--------+-------+---\\---+-------+---##---+---//--+---- | | | | \---+-------+--------+---/ | | | | | | | (a) | | ----+-------+--------+---\ | | | | | <---+-------+--------+---\\--+---##---+--\ | | | | | | \--+---##---+--\\ | | | | | | | (b) | \\--+--------+-------+---> | | | | | \--+--------+-------+---- | | | | | | | | +-------+ +-------+ +-------+ +-------+ Figure 8 Two types of data link failures (indicated with ##) Data link Activation Indication The ChannelStatus message may also be used to notify an LMP neighbor that the data link should be actively monitored. This is called Data Link Activation Indication. This is particularly useful in networks with transparent OXC nodes where the fault monitoring of data links Everdingen et al [Page 20] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 may need to be triggered using messages over the control plane. Active monitoring MAY be used before user traffic is allowed on the data link. The ChannelStatus message is used to indicate that a data link or group of data links are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message. When a ChannelStatus message is received, the node must send a signal on the corresponding data link(s). If the downstream node consequently detects a failure, the ChannelStatus message MUST be transmitted as described in Section 6.2. Data Link Deactivation Indication The ChannelStatus message MAY also be used to notify an LMP neighbor that the data link no longer needs to be actively monitored. This is the counterpart to the Data Link Active Indication. When a ChannelStatus message is received with Data Link Deactive Indication, the node MAY remove the signal from the corresponding data link(s). 7. Message_Id Usage The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP messages to support reliable message delivery. This section describes the usage of these objects. The MESSAGE_ID and MESSAGE_ID_ACK objects contain a Message_Id field. Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message. The Message_Id field is within the scope of the LMP adjacency. The Message_Id field of the MESSAGE_ID object MUST contain a monotonically increasing value. The Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id field of the message being acknowledged. Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached. Nodes processing incoming messages SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages can be identified by examining the value in the Message_Id field. If the Message_Id value is less than the largest Message_Id value previously received from the sender of the LMP adjacency, then the message SHOULD be treated as being out of order and consequently be ignored. 8. Graceful Restart Everdingen et al [Page 21] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 This section describes the mechanism to resynchronize the LMP state between LMP adjacencies. Resynchronization is needed in case of an LMP component restart. Note that resynchronization is not needed in case of a failure in the control plane. Normal retransmission timers for the linkSummary and channelStatus messages take care of resynchronization as soon as the connectivity between LMP adjacencies is restored. If the control plane failure was the result of an LMP component restart, then the "LMP Restart" flag MUST be set in all LMP messages until the LMP adjacency has acknowledged the reception of the linkSummary and the channelStatusRequest message. Upon restart of the LMP component, this component MUST send a LinkSummary message for each TE Link across the adjacency. All the objects of the LinkSummary message MUST have the N-bit set to 0 indicating that the parameters are non-negotiable. This provides the local/remote Link Id and Interace Id mappings, the associated TE Link and data link parameters, and indication of which data links are currently allocated to user traffic. When the LMP adjacency receives the LinkSummary message, it checks the consistency with its local configuration as described in Section 4 with the exception that the allocated/deallocated flag of the DATA_LINK Object received in the LinkSummary message MUST take precedence over any local value. If, however, the LMP adjacency was not capable of retaining the LMP Link information across a restart, the node MUST accept the TE link and data link parameters of the received LinkSummary message and respond with a LinkSummaryAck message. Upon completion of the LinkSummary exchange, the restarted LMP component SHOULD send a ChannelStatusRequest message for all TE links. The restarted LMP component SHOULD also verify the connectivity of all unallocated data links. Everdingen et al [Page 22] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 9. Addressing All LMP messages are sent over UDP. The destination address of the IP packet MUST be either the address learned in a manual configuration procedure or the address learned in the automatic neighbor discovery procedure. 10. LMP Authentication LMP authentication is optional (included in the Common Header) and, if used, MUST be supported by both nodes that are neighbors regarding the data links. The method used to authenticate LMP packets is based on the authentication technique used in [OSPF]. This uses cryptographic authentication using MD5. As a part of the LMP authentication mechanism, a flag is included in the LMP common header indicating the presence of authentication information. Authentication information itself is appended to the LMP packet. It is not considered to be a part of the LMP packet, but is transferred in the same IP packet. When the Authentication flag is set in the LMP packet header, an authentication data block is attached to the packet. This block has a standard authentication header and a data portion. The contents of the data portion depend on the authentication type. Currently, only MD5 is supported for LMP. 11. IANA Considerations LMP defines the following name spaces that require management: - Msg Type Name Space. - LMP Object Class name space. - LMP Object Class type (C-Type). These are unique with Object Class. Following the policies outlined in [IANA], Msg Type, Object Class, and Class type are allocated through an IETF Consensus action. Everdingen et al [Page 23] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 12. LMP Finite State Machines 12.1. TE Link FSM The TE Link FSM defines the states and logics of operation of an LMP TE Link. Note that the TE link (in contrast to the data link) offers bi-directional transmission. The TE link is considered 'up' in case both ends of the TE link have received the linkSummaryAck message. 12.1.1. TE Link States An LMP TE link can be in one of the states described below. Every state corresponds to a certain condition of the TE link. Down: There are no data links allocated to the TE link. Init: Data links have been allocated to the TE link, but the configuration has not yet been synchronized with the LMP neighbor. Up: This is the normal operational state of the TE link. 12.1.2. TE Link Events Operation of the LMP TE link is described in terms of FSM states and events. Every event has its number and a symbolic name. Description of possible TE link events is given below. 1 : evDLUp: The number of data links in the TE link has been changed. The resulting TE link contains at least one data chennel. 2 : evSumAck: LinkSummary message received and positively acknowledged. 3 : evSumNack: LinkSummary message received and negatively acknowledged. 4 : evRcvAck: LinkSummaryAck message received acknowledging the TE Link Configuration. 5 : evRcvNack: LinkSummaryNack message received. 6 : evSumRet: Retransmission timer has expired and LinkSummary message is resent. 7 : evDLDown: Last data link of the TE link has been removed. 12.1.3. TE Link FSM Description Figure 9 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram. Everdingen et al [Page 24] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 3 +--+ | | | v +--------+ | | | Down |<---------+ | | | +--------+ | | ^ | 1| |7 | v | | +--------+ | | |<-+ 2, | | Init | |3,5,6 |7 | |--+ | +--------+ | | ^ | 4| | 1,3,5 | v | | +--------+ | | |----------+ | Up | | | +--------+ | ^ | | +--+ 2,4,6 Figure 9: LMP TE Link FSM 12.2. Data Link FSM The data link FSM defines the states and logics of operation of a data link within an LMP TE link. Operation of a data link is described in terms of FSM states and events. The end points of data links can either be in the transmitting mode or in the receiving mode. For clarity, separate FSMs are defined for these modes. 12.2.1. Data Link States Any data link can be in one of the states described below. Every state corresponds to a certain condition of the TE link. Down: The data link has not been put in the resource pool (i.e., the data link is not "in service" Test: A test signal is sent over the data link. Everdingen et al [Page 25] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 PasvTest: The data link is being checked for an incoming test signal. Up/Free: The data link has been successfully tested and is now put in the pool of resources (in-service). The link has not yet been allocated to data traffic. Up/Allocated: The link is UP and has been allocated for data traffic. 12.2.2. Data Link Events Data bearing link events are generated by the FSMs of the associated TE link. Every event has its number and a symbolic name. Description of possible data link events is given below: 3 :evStartTst: This is an external event that triggers the sending of the test signal over the data bearing link. 4 :evStartPsv: This is an external event that triggers the listening for a test signal over the data bearing link. 5 :evTestOK: Link verification was successful and the link can be used for path establishment. This event indicates the Link Verification procedure (see Section 5) was successful for this data link and a TestStatusSuccess message was received. 6 :evTestRcv: Test signal was received over the data link and a TestStatusSuccess message is transmitted over the control network. 7 :evTestFail: Link verification returned negative results. This could be because (a) a TestStatusFailure message was received, or (b) the Verification procedure has ended without receiving a TestStatusSuccess or TestStatusFailure message for the data link. 8 :evPsvTestFail:Link verification returned negative results. This indicates that a Test message was not detected and either (a) the VerifyDeadInterval has expired or (b) the Verification procedure has ended and the VerifyDeadInterval has not yet expired. 9 :evLnkAlloc: The data link has been allocated. 10:evLnkDealloc: The data link has been deallocated. 11:evTestRet: A retransmission timer has expired and the Test signal is resent. 12:evSummaryFail:The LinkSummary did not match for this data port. 13:evLocalizeFail:A Failure has been localized to this data link. 14:evdlDown: The data link is no longer available. 12.2.3. FSM Description Transmitter Figure 10 illustrates operation of the transmitting side of the data link in the form of FSM state transition diagram. Everdingen et al [Page 26] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Note that the FSM may start in the Up/Free state. This may be the case when the data link has been discovered via LMP's automatic neighbor discovery procedure. +------+ | |<-------+ +--------->| Down | | | | |<-----+ | | +------+ | | | 3| ^ | | | | |2,7 | | | v | | | | +------+ | | | | |<-+ | | | | Test | |11 | | |12 | |--+ | | | +------+ | | | 5| 3^ | | | | | | | | v | | | | +---------+ | | | | |14 | | | | Up/Free |----+ | +---------| | | +---------+ | 9| ^ | | | | v |10 | +---------+ | | |13 | |Up/Alloc |------+ | | +---------+ Figure 10: FSM description of transmitting side of Data Link Everdingen et al [Page 27] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 12.2.4. FSM Description receiver Figure 11 illustrates operation of the receiving side of the data link in the form of FSM state transition diagram. Note that the FSM may start in the Up/Free state. This may be the case when the data link has been discovered via LMP's automatic neighbor discovery procedure. +------+ | |<------+ +---------->| Down | | | | |<----+ | | +------+ | | | 4| ^ | | | | |2,8 | | | v | | | | +----------+ | | | | PasvTest | | | |12 +----------+ | | | 6| 4^ | | | | | | | | v | | | | +---------+ | | | | Up/Free |14 | | | | |---+ | +----------| | | +---------+ | 9| ^ | | | | v |10 | +---------+ | | |13 | |Up/Alloc |-----+ | | +---------+ Figure 11: FSM description of receiving side of Data Link Everdingen et al [Page 28] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 13. LMP Message Formats All LMP messages are UDP encoded with port number xxx - TBA (to be assigned) by IANA. 13.1. Common Header In addition to the standard UDP header, all LMP messages have the following common header: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | (Reserved) | Flags | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers: 4 bits Protocol version number. This is version 1. Flags: 8 bits. The following values are defined. All other values are reserved. 0x02: LMP Restart This bit is set to indicate the LMP component has restarted. 0x08: Authentication When set, this bit indicates that an authentication block is attached at the end of the LMP message. See Section 10 for more details. Msg Type: 8 bits. The following values are defined. All other values are reserved. 5 = BeginVerify 6 = BeginVerifyAck 7 = BeginVerifyNack 8 = EndVerify 9 = EndVerifyAck 11 = TestStatusSuccess 12 = TestStatusFailure 13 = TestStatusAck Everdingen et al [Page 29] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 14 = LinkSummary 15 = LinkSummaryAck 16 = LinkSummaryNack 17 = ChannelStatus 18 = ChannelStatusAck 19 = ChannelStatusRequest 20 = ChannelStatusResponse 13.2. LMP Object Format LMP messages are built using objects. Each object is identified by its Object Class and Class-type. Each object has a name, which is always capitalized in this document. LMP objects can be either negotiable or non-negotiable (identified by the N bit in the Object header). Negotiable objects can be used to let the devices agree on certain values. Non-negotiable Objects are used for announcement of specific values that do not need or do not allow negotiation. The format of the LMP object is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| C-Type | Class | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N: 1 bit The N flag indicates if the object is negotiable (N=1) or non- negotiable (N=0). C-Type: 7 bits Class-type, unique within an Object Class. Values are defined in Section 14. Class: 8 bits The Class indicates the Object type. Each Object has a name, which is always capitalized in this document. Everdingen et al [Page 30] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Length: 16 bits The Length field indicates the length of the Object in bytes, including the N, C-Type, Class, and Length fields. 13.3. Authentication When authentication is used for LMP, the authentication itself is appended to the LMP packet. It is not considered to be a part of the LMP packet, but is transmitted in the same UDP packet as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // LMP Common Header // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // LMP Payload // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Authentication Block // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The authentication block consists of an 8 byte header followed by the data portion shown as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Auth Type | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MD5 Signature (16) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Type: 8 bits This defines the type of authentication used for LMP messages. The following authentication types are defined, all other are reserved for future use: 0 No authentication 1 Cryptographic authentication Key ID: 8 bits Everdingen et al [Page 31] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 This field is defined only for cryptographic authentication. Auth Data Length: 8 bits This field contains the length of the data portion of the authentication block. The LMP packet authentication procedure is very similar to the one used in OSPF, including multiple key support, key management, etc. The details specific to LMP are defined below. Sending authenticated packets ----------------------------- When a packet needs to be sent over the control network and an authentication method is configured for it, the Authentication flag in the LMP header is set to 1, the LMP Length field is set to the length of the LMP packet only, not including the authentication block. 1) The Checksum field in the LMP packet is set to zero (this will make the receiving side drop the packet if authentication is not supported). 2) The LMP authentication header is filled out properly. The message digest is calculated over the LMP packet together with the LMP authentication header. The input to the message digest calculation consists of the LMP packet, the LMP authentication header, and the secret key. When using MD5 as the authentication algorithm, the message digest calculation proceeds as follows: (a) The authentication header is appended to the LMP packet. (b) The 16 byte MD5 key is appended after the LMP authentication header. (c) Trailing pad and length fields are added, as specified in [MD5]. (d) The MD5 authentication algorithm is run over the concatenation of the LMP packet, authentication header, secret key, pad and length fields, producing a 16 byte message digest (see [MD5]). (e) The MD5 digest is written over the secret key (i.e., appended to the original authentication header). The authentication block is added to the IP packet right after the LMP packet, so IP packet length includes the length of both LMP packet and LMP authentication blocks. Receiving authenticated packets ------------------------------- When an LMP packet, with the Authentication flag set, has been received, it must be authenticated. The value of the Authentication field MUST match the configured authentication type. Everdingen et al [Page 32] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 If an LMP protocol packet is accepted as authentic, processing of the packet continues. Packets that fail authentication are discarded. Note that the checksum field in the LMP packet header is not checked when the packet is authenticated. (1) If the key is not configured, or if the key is not valid for reception (i.e., current time does not fall into the key's active time frame), the LMP packet is discarded. (2) If the cryptographic sequence number found in the LMP authentication header is less than the cryptographic sequence number recorded in the node, the LMP packet is discarded. (3) Verify the message digest in the data portion of the authentication block in the following steps: (a) The received digest is set aside. (b) A new digest is calculated, as specified in the previous section. (c) The calculated and received digests are compared. If they do not match, the LMP packet is discarded. If they do match, the LMP protocol packet is accepted as authentic, and the "cryptographic sequence number" in the node's data structure is set to the sequence number found in the packet's LMP header. 13.4. Link Verification 13.4.1. BeginVerify Message (Msg Type = 5) The BeginVerify message is sent over the control network and is used to initiate the link verification process. The format is as follows: ::= The above transmission order SHOULD be followed. To limit the scope of Link Verification to a particular TE Link, the LOCAL_LINK_ID and REMOTE_LINK_ID MUST be non-zero. The BeginVerify message MUST be periodically transmitted until (1) the node receives either a BeginVerifyAck or BeginVerifyNack message to accept or reject the verify process or (2) a timeout expires and no BeginVerifyAck or BeginVerifyNack message has been received. Both the retransmission interval and the timeout period are local configuration parameters. 13.4.2. BeginVerifyAck Message (Msg Type = 6) When a BeginVerify message is received and test signals are ready to be processed, a BeginVerifyAck message MUST be transmitted. ::= Everdingen et al [Page 33] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged. The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. This value is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel test procedures between the same LMP neighbors. 13.4.3. BeginVerifyNack Message (Msg Type = 7) If a BeginVerify message is received and a node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted. ::= The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged. If the Verification process is not supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported". If Verification is supported, but the node unable to begin the procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a BeginVerifyNack message is received with such an ERROR_CODE, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter. If the Verification Transport mechanism is not supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism". If the LOCAL_LINK_ID, REMOTE_LINK_ID combination in the BeginBVerify message does not match the node's configuration, the ERROR_CODE MUST indicate "TE Link Id configuration error". The BeginVerifyNack uses BEGIN_VERIFY_ERROR_ C-Type 2. 13.4.4. EndVerify Message (Msg Type = 8) The EndVerify message is sent over the control network and is used to terminate the link verification process. The EndVerify message may Everdingen et al [Page 34] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 be sent at any time the initiating node desires to end the Verify procedure. The format is as follows: ::= The above transmission order SHOULD be followed. The EndVerify message will be periodically transmitted until (1) an EndVerifyAck message has been received or (2) a timeout expires and no EndVerifyAck message has been received. Both the retransmission interval and the timeout period are local configuration parameters. 13.4.5. EndVerifyAck Message (Msg Type =9) The EndVerifyAck message is sent over the control network and is used to acknowledge the termination of the link verification process. The format is as follows: ::= The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged. 13.4.6. TestStatusSuccess Message (Msg Type = 11) The TestStatusSuccess message is transmitted over the control network and is used to transmit the mapping between the local Interface Id and the Interface Id that was received in the Test message. ::= The above transmission order SHOULD be followed. The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding test signal being positively acknowledged. 13.4.7. TestStatusFailure Message (Msg Type = 12) The TestStatusFailure message is transmitted over the control network and is used to indicate that the test signal was not received. ::= The above transmission order SHOULD be followed. Everdingen et al [Page 35] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 13.4.8. TestStatusAck Message (Msg Type = 13) The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages. ::= The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged. 13.5. Link Summary Messages 13.5.1. LinkSummary Message (Msg Type = 14) The LinkSummary message is used to synchronize the Interface Ids and correlate the properties of the TE link. The format of the LinkSummary message is as follows: ::= [...] The above transmission order SHOULD be followed. The LinkSummary message can be exchanged at any time a link is not in the Verification process. The LinkSummary message MUST be periodically transmitted until (1) the node receives a LinkSummaryAck or LinkSummaryNack message or (2) a timeout expires and no LinkSummaryAck or LinkSummaryNack message has been received. Both the retransmission interval and the timeout period are local configuration parameters. 13.5.2. LinkSummaryAck Message (Msg Type = 15) The LinkSummaryAck message is used to indicate agreement on the Interface Id synchronization and acceptance/agreement on all the link parameters. It is on the reception of this message that the local node makes the TE Link Id associations. ::= The above transmission order SHOULD be followed. 13.5.3. LinkSummaryNack Message (Msg Type = 16) The LinkSummaryNack message is used to indicate disagreement on non- negotiated parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the LinkSummaryNack Object. ::= Everdingen et al [Page 36] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 [...] The above transmission order SHOULD be followed. The DATA_LINK Objects MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes DATA_LINK Objects for non-negotiable parameters, they MUST be copied from the DATA_LINK Objects received in the LinkSummary message. If the LinkSummaryNack message is received and only includes negotiable parameters, then a new LinkSummary message SHOULD be sent. The values received in the new LinkSummary message SHOULD take into account the acceptable parameters included in the LinkSummaryNack message. The LinkSummaryNack message uses LINK_SUMMARY_ERROR C-Type 2. 13.6. Fault Management Messages 13.6.1. ChannelStatus Message (Msg Type = 17) The ChannelStatus message is sent over the control network and is used to notify an LMP neighbor of the status of a data link. A node that receives a ChannelStatus message MUST respond with a ChannelStatusAck message. The format is as follows: ::= The above transmission order SHOULD be followed. If the CHANNEL_STATUS object does not include any Interface Ids, then this indicates the entire TE Link has failed. 13.6.2. ChannelStatusAck Message (Msg Type = 18) The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus Message. The format is as follows: ::= The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged. 13.6.3. ChannelStatusRequest Message (Msg Type = 19) The ChannelStatusRequest message is sent over the control network and is used to request the status of one or more data link(s). A node that receives a ChannelStatusRequest message MUST respond with a ChannelStatusResponse message. The format is as follows: Everdingen et al [Page 37] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 ::= [] The above transmission order SHOULD be followed. If the CHANNEL_STATUS_REQUEST object is not included, then the ChannelStatusRequest is being used to request the status of ALL of the data link(s) of the TE Link. 13.6.4. ChannelStatusResponse Message (Msg Type = 20) The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest Message and notify the LMP neighbor of the status of the data link(s). The format is as follows: ::= The above transmission order SHOULD be followed. The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged. Everdingen et al [Page 38] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 14. LMP Object Definitions 14.1. NODE_ID Classes 14.1.1. LOCAL_NODE_ID Class Class = 3. IPv4, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6, C-Type = 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Node_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identifies the address (in the control plane) of the node that originated the LMP packet. This Object is non-negotiable. 14.1.2. REMOTE _NODE_ID Class Class = 4. IPv4, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6, C-Type = 2 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 Everdingen et al [Page 39] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Node_Id (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Node_Id: This identities the remote node. This Object is non-negotiable. 14.2. LINK _ID Classes 14.2.1. LOCAL_LINK_ID Class Class = 5 C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link_Id: This identifies the sender's Link associated with the message. This Object is non-negotiable. 14.2.2. REMOTE _LINK_ID Class Class = 6 C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link_Id: This identifies the remote node's Link Id and MUST be non-zero. This Object is non-negotiable. Everdingen et al [Page 40] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 14.3. INTERFACE_ID Classes 14.3.1. LOCAL_INTERFACE_ID Class Class = 7 C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface_Id: This identifies the data link (either port or component link). The Interface_Id MUST be node-wide unique and non-zero. The Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit into the in-band discovery and test messages. This Object is non-negotiable. 14.3.2. REMOTE_INTERFACE_ID Class Class = 8. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface_Id: This identifies the remote node's data link (either port or component link). The Interface Id MUST be non-zero. The Interface ID MUST be a number 0x00000-0xFFFFF to be able to fit into the in-band discovery and test messages. This Object is non-negotiable. 14.4. MESSAGE_ID Class Class = 9. MessageId, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Everdingen et al [Page 41] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Message_Id: The Message_Id field is used to identify a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgment. This Object is non-negotiable. 14.5. MESSAGE_ID_ACK Class Class = 10. MessageIdAck, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message_Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message_Id: The Message_Id field is used to identify the message being acknowledged. This value is copied from the MESSAGE_ID object of the message being acknowledged. This Object is non-negotiable. 14.6. BEGIN_VERIFY Class Class = 13. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Data Links (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | local interface id. #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | local interface id. #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number of Data Links: 32 bits This is the number of data links that will be verified. Interface_Id: Everdingen et al [Page 42] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 This identifies the local node's data link (either port or component link) that is to be verified. 14.7. BEGIN_VERIFY_ACK Class Class = 14. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VerifyDeadInterval | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VerifyDeadInterval: 16 bits If a Test message is not detected within the VerifyDeadInterval, then a node will send the TestStatusFailure message for that data link. This Object is non-negotiable. 14.8. VERIFY_ID Class Class = 15. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VerifyId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VerifyId: 32 bits This is used to differentiate Test messages from different TE links and/or LMP peers. This is a node-unique value that is assigned by the recipient of the BeginVerify message. This Object is non-negotiable. 14.9. TE_LINK Class Class = 16. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Link_Id (4 bytes) | Everdingen et al [Page 43] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Link_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 16 bits The following flags are defined. All other values are reserved. 0x01 Fault Management Supported. 0x02 Link Verification via access point identifier method supported. Local_Link_Id: This identifies the node's local Link Id and MUST be non-zero. Remote_Link_Id: This identifies the remote node's Link Id and MUST be non-zero. 14.10. DATA_LINK Class Class = 17. C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote_Interface_Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 8 bits The following flags are defined. All other values are reserved. 0x02 Allocated Link: If set, the data link is currently allocated for user traffic. If a single Interface_Id is used for both the transmit and receive data links, then this bit only applies to the transmit interface. 0x04 Failed Link: If set, the data link is failed and not suitable for user traffic. Local_Interface_Id: Everdingen et al [Page 44] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 This is the local identifier of the data link. This MUST be node-wide unique and non-zero. Remote_Interface_Id: This is the remote identifier of the data link. This MUST be non-zero. Subobjects The contents of the data link object MAY consist of a series of variable-length data items called subobjects. The subobjects are defined in subsequent sub-sections. The contents of the DATA_LINK object include a series of variable- length data items called subobjects. Each subobject has the form: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ | Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------//---------------+ Type: 8 bits The Type indicates the type of contents of the subobject. Length: 8 bits The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. 14.10.1. Subobject Type 1: Local Access Identifier (Local AID) The Local Access Identifier (Local AID) identifies the local interface_id in a human-readable format. The format of the local AID is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ | Type | Length | local AID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ local AID: Any human-readable string. Everdingen et al [Page 45] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 14.10.2. Subobject Type 2: Remote Access Identifier (Local AID) The Remote Access Identifier (Remote AID) identifies the remote interface_id in a human-readable format. The format of the remote AID is as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ | Type | Length | remote AID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------//------------------+ remote AID: Any human-readable string. 14.10.3. Subobject Type 3: Shared Risk Link Group Identifier (SRLG) SRLGs of which the data link is a member. This information is manually configured per data link may be used for diverse path computation. The format of the SRLG sub-object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG value #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG value #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits The length is (N+1)*4, where N is the number of SRLG values. Shared Risk Link Group Value: 32 bits List as many SRLGs as apply. Reserved: 16 bits Must be set to zero on transmit and ignored on receive. 14.10.4. Subobject Type 4: multiplex protection Everdingen et al [Page 46] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 The contents of the multiplex protection object determine whether the data link is protected on multiplex level. Examples of protection schemes on multiplex level: MSP/line protection, MS-SPRing/BLSR etcetera. This information can be used as a measure of the quality of the data link. It may be advertised by routing and used by signaling as a selection criterion as described in [GMPLS]. The format of the Optical Protection subobject is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link Flags| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits The length field has value '4'. Link Flags: 6 bits Encoding for Link Flags can be found in [GMPLS]. 14.10.5. Subobject Type 5: Total Span delay The total span delay object determines the delay any bit experiences when travelling over the data link. The format of the span delay sub-object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Span Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits The length field has value '8'. Span Length: 32 bits Total Length of the WDM span in meters expressed as an unsigned integer. Reserved: 16 bits Must be set to zero on transmit and ignored on receive. 14.10.6. Subobject Type 6: Administrative Cost Everdingen et al [Page 47] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 The administrative cost sub-object gives the cost of the data link for path routing purposes. This information is manually configured per data link. The format of the Administrative Group sub-object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrative Cost (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Administrative Cost: 32 bits A 32 bit value. Reserved: 16 bits Must be set to zero on transmit and ignored on receive. 14.11. CHANNEL_STATUS Class Class = 18 C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Channel Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Active bit: 1 bit This indicates that the data link is allocated to user traffic and the data link should be actively monitored. Direction bit: 1 bit Everdingen et al [Page 48] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 This indicates the direction (transmit/receive) of the data link referred to in the Channel_Status object. If set, this indicates the data channel is in the transmit direction. Channel_Status: 31 bits This indicates the status condition of a data link. The following values are defined. All other values are reserved. 1. Signal Okay (OK): Data link is operational 2. Signal Degrade (SD): A soft failure caused by a BER exceeding a preselected threshold. The specific BER used to define the threshold is configured. 3. Signal Fail (SF): A hard signal failure including (but not limited to) loss of signal (LOS), loss of frame (LOF), or Line AIS. This Object contains one or more Interface Ids followed by a Channel_Status field. To indicate the status of the entire TE Link, there MUST only be one Interface Id and it MUST be zero. This Object is non-negotiable. 14.12. CHANNEL_STATUS_REQUEST Class Class = 19 C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Object contains one or more Interface Ids. The Length of this object is 4N in bytes, where N is the number of Interface Ids. This Object is non-negotiable. 14.13. ERROR_CODE Class Class = 20. BEGIN_VERIFY_ERROR, C-Type = 1 Everdingen et al [Page 49] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Link Verification Procedure not supported for this TE Link. 0x02 = Unwilling to verify at this time 0x08 = TE Link Id configuration error All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. If a BeginVerifyNack message is received with Error Code 2, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter. LINK_SUMMARY_ERROR, C-Type = 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following bit-values are defined: 0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters 0x02 = Renegotiate LINK_SUMMARY parameters 0x04 = Bad Received Remote_Link_Id 0x08 = Bad TE Link Object 0x10 = Bad Data Link Object All other values are Reserved. Multiple bits may be set to indicate multiple errors. This Object is non-negotiable. Everdingen et al [Page 50] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 15. Security Considerations LMP exchanges may be authenticated using the Cryptographic authentication option. MD5 is currently the only message digest algorithm specified. 16. References [RFC2026] Bradner, S., "The Internet Standards Process-Revision 3," BCP 9, RFC 2026, October 1996. [LAMBDA] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," Internet Draft, draft-awduche-mpls-te-optical-03.txt, (work in progress), April 2001. [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering," Internet Draft, draft- kompella-mpls-bundle-05.txt, (work in progress), February 2001. [RSVP-TE] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp- tunnel-08.txt, (work in progress), February 2001. [CR-LDP] Jamoussi, B., et al, "Constraint-Based LSP Setup using LDP," Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, (work in progress), September 1999. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF," Internet Draft, draft-katz-yeung- ospf-traffic-04.txt, (work in progress), February 2001. [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering," Internet Draft,draft-ietf-isis-traffic- 02.txt, (work in progress), September 2000. [OSPF] Moy, J., "OSPF Version 2," RFC 2328, April 1998. [LMP] Lang, J.P. et al, "Link Management Protocol", Internet Draft, draft-ietf-ccamp-lmp-03.txt, (work in progress), March 2002. [LMP-DWDM] Fredette, A., Lang, J. P., editors, "Link Management Protocol (LMP) for WDM Transmission Systems,÷ Internet Draft, draft-fredette-lmp-wdm-03.txt, (work in progress), November 2001. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992. [GMPLSSIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized MPLS - Signaling Functional Description," Internet Draft, draft-ietf-mpls-generalized-signaling-06.txt, (work in progress), October 2001. [G707] ITU-T G.707, "Network node interface for the synchronous digital hierarchy (SDH)," March 1996. [G783] ITU-T G.783, "Characteristics of Synchronous Digital Hierarchy (SDH) equipment functional blocks," October 2000. [GR253] GR-253-CORE, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria," Telcordia Everdingen et al [Page 51] Internet Draft draft-everdingen-ccamp-lmp-update-00 June 2002 Technologies, Issue 3, September 2000. [LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with MPLS TE," Internet Draft, draft-ietf-mpls-lsp-hierarchy- 02.txt, (work in progress), February 2001. [OIF-UNI] The Optical Internetworking Forum, "UNI 1.0 Signaling Specification", October, 2001. [NDP-PPP] J. Sadler et al, "Neighbor Discovery via PPP", Internet draft draft-sadler-pppext-disc-01.txt, June 2002. 17. Authors' Addresses Michiel van Everdingen Lucent Technologies P.O. Box 18 1270 AA Huizen The Netherlands Email: MvanEverdingen@lucent.com Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014 Phone: (510) 573-2237 Email: gregb@ciena.com Everdingen et al [Page 52]