--- 1/draft-ietf-ccamp-confirm-data-channel-status-03.txt 2009-05-23 04:12:03.000000000 +0200 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-04.txt 2009-05-23 04:12:03.000000000 +0200 @@ -1,26 +1,26 @@ Network Working Group D. Li Internet Draft H. Xu Category: Standards Track Huawei S. Bardalai Fujitsu J. Meuric France Telecom D. Caviglia Ericsson -Expires: November 2009 May 6, 2009 +Expires: November 2009 May 22, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-03.txt + draft-ietf-ccamp-confirm-data-channel-status-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. @@ -30,62 +30,62 @@ 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 - As LMP is already used to verify data plane connectivity, it is - considered to be an appropriate candidate to support this feature. This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying - the management plane if any discrepancies are found. + the management plane if any discrepancies are found. As LMP is + already used to verify data plane connectivity, it is considered to + be an appropriate candidate to support this feature. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Problem Explanation..........................................4 2.1. Mismatch Caused by Manual Configuration.................4 2.2. Mismatch Caused by LSP Deletion.........................5 - 2.3. Manual Change of the Cross-Connection State.............5 - 2.4. Failed Resources........................................6 + 2.3. Failed Resources........................................5 3. Motivation...................................................6 4. Extensions to LMP............................................7 4.1. Confirm Data Channel Status Messages....................7 4.1.1. ConfirmDataChannelStatus Messages..................7 4.1.2. ConfirmDataChannelStatusAck Messages...............8 4.1.3. ConfirmDataChannelStatusNack Messages..............8 4.2. Data Channel Status Subobject...........................9 + 4.3. Message Construction...................................10 5. Procedures..................................................10 6. Security Considerations.....................................11 7. IANA Considerations.........................................12 7.1. LMP Message Types......................................12 7.2. LMP Data Link Object Subobject.........................12 8. Acknowledgments.............................................12 9. References..................................................12 9.1. Normative References...................................12 9.2. Informative References.................................13 10. Authors' Addresses.........................................13 - 11. Full Copyright Statement...................................15 + 11. Full Copyright Statement...................................14 12. Intellectual Property Statement............................15 - 13. Disclaimer of Validity.....................................16 + 13. Disclaimer of Validity.....................................15 1. Introduction Generalized Multiprotocol Label Switching (GMPLS) networks are constructed from Traffic Engineering (TE) links connecting Label Switching Routers (LSRs). The TE links are constructed from a set of data channels. In this context, a data channel corresponds to a resource label in a non-packet technology (such as a timeslot or a lambda). @@ -130,27 +130,27 @@ described as "stranded resources". They are not in use for any LSP, but they cannot be assigned for use by a new LSP because they appear to be in use. Although it is theoretically possible for management plane applications to audit all network resources to locate stranded resources and to release them, this process is rarely performed because of the difficulty of coordinating different Element Management Systems (EMSs), and the associated risks of accidentally releasing in-use resources. It is desirable to have a control plane mechanism that detects and reports stranded resources. - As LMP is already used to verify data plane connectivity, it is - considered to be an appropriate candidate to support this feature. This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for - notifying the management plane if any discrepancies are found. + notifying the management plane if any discrepancies are found. As LMP + is already used to verify data plane connectivity, it is considered + to be an appropriate candidate to support this feature. 2. Problem Explanation Examples of data channel mismatches are described in the following three scenarios. In all of the scenarios, the specific channel resource of a data link will be unavailable because of the data channel status mismatch, and this channel resource will be wasted. Furthermore, a data channel status mismatch may reduce the possibility of successful LSP @@ -200,43 +200,37 @@ of node B still being in use. So the data channel statuses between nodes A and B, and between nodes B and C are both mismatched. <---------LSP---------> +-+-------+-+-------+-+ | | |X| | | +-+-------+-+-------+-+ A B C Figure 2. Mismatch caused by LSP deletion - RSVP-TE restart processes [RFC2205], [RFC3209], [RFC3473], [RFC5063] - define mechanisms where adjacent LSRs may resynchronize their control - plane state to reinstate information about LSPs that have persisted - in the data plane. The mechanisms allow LSRs to detect mismatched - data plane state after the expiry of the Recovery Timer. It is a - local policy decision how this mismatched state is handled. Some + In [RFC2205] and [RFC3209], a soft state mechanism was defined to + prevent state discrepancies between LSRs. RSVP-TE restart processes + ([RFC3473], [RFC5063]) have been defined: adjacent LSRs may + resynchronize their control plane state to reinstate information + about LSPs that have persisted in the data plane. Both mechanisms aim + at keeping state consistency among nodes and allow LSRs to detect + mismatched data plane states. The data plane handling of such + mismatched state can be treated as a local policy decision. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use. In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures. -2.3. Manual Change of the Cross-Connection State - - In transport nodes it is possible to perform certain manual - operations on a cross-connect such as forced protection switch - (refer to [G.841]) on a protected link. These operations will make - it impossible to release the cross-connect when an LSP is being - deleted. - -2.4. Failed Resources +2.3. Failed Resources Even if the situation is not common, it might happen that a termination point of a TE-link is seen as failed by one end, while on the other end it is seen as OK. This problem may arise due to some failure either in the hardware or in the status detection of the termination point. This mismatch in the termination point status can lead to failure in case of bidirectional LSP set-up. @@ -292,29 +286,28 @@ Extensions to LMP to confirm a data channel status are described below. In order to confirm a data channel status, the new LMP messages are sent between adjacent nodes periodically or driven by some event (such as an operator command, a configurable timer, or the rejection of an LSP setup message because of an unavailable resource). The new LMP messages run over the control channel, encapsulated in UDP with an LMP port number and IP addressing as defined in Link Management Protocol (LMP) [RFC4204]. - 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 a message is determined to be out-of-order, that message - should be silently dropped. - Three new messages are defined to check data channel status. Message Type numbers are found in Section 7.1. + If the message is a Confirm Data Channel Status message, and the + Message_Id value is less than the largest Message_Id value previously + received from the sender for the specified TE link, then the message + SHOULD be treated as being out-of-order. + 4.1.1. ConfirmDataChannelStatus Messages The ConfirmDataChannelStatus message is used to tell the remote end of the data channel what the status of the local end of the data channel is, and to ask the remote end to report its data channel. The message may report on (and request information about) more than one data channel. ::= @@ -415,78 +409,89 @@ in the Length field. Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message. The data-channel ID must be encoded as a label value. Based on the type of signal e.g. SONET/SDH, Lambda etc. the encoding methodology used will be different. For SONET/SDH the label value is encoded as per RFC4606. +4.3. Message Construction + + Data_Link Class is included in ConfirmDataChannelStatus and + ConfirmDataChannelStatusAck messages, which is defined in section + 13.12 in [RFC4204]. + + The status of the TE link end MUST be carried by the Data Channel + Status subobject which is defined in section 4.2 of this document. + The new subobject MUST be part of Data_Link Class. + + In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD + be used to identify each timeslot of the data link. + 5. Procedures - The data channel status confirmation related LMP messages are sent - between adjacent nodes periodically or driven by some events to - confirm the channel status for the data links. The procedure is - described below: + The data channel status confirmation related LMP messages MAY be sent + between adjacent nodes which are triggered by timer periodically or + driven by some events to confirm the channel status for the data + links. It's a local police decision to start the data channel status + confirmation process. The procedure is described below: . The SENDER constructs a ConfirmDataChannelStatus message which - contains one or more DATA_LINK objects. DATA_LINK object is - defined in [RFC4204]. Each DATA_LINK object contains one or more - Data Channel Status subobject. The Data Channel ID field in the - Data Channel Status subobject indicates which data channel needs - to be confirmed, and reports the data channel status at the SENDER. - The ConfirmDataChannelStatus message is sent to the RECEIVER. + MUST contain one or more DATA_LINK objects. DATA_LINK object is + defined in [RFC4204]. Each DATA_LINK object MUST contain one or + more Data Channel Status subobjects. The Data Channel ID field in + the Data Channel Status subobject MUST indicate which data channel + needs to be confirmed, and MUST report the data channel status at + the SENDER. The ConfirmDataChannelStatus message is sent to the + RECEIVER. - . The RECEIVER extracts the data channel statuses from the - ConfirmDataChannelStatus message, and compares these with its data - channel statuses for the reported data channels. If a data channel - status mismatch is found, the mismatch result SHOULD be reported - to the management plane for further action. The RECEIVER also - sends the ConfirmDataChannelStatusAck message which carries all - the local end statuses of the requested data channels to the - SENDER. + . The RECEIVER MUST extract the data channel statuses from the + ConfirmDataChannelStatus message, and SHOULD compare these with + its data channel statuses for the reported data channels. If a + data channel status mismatch is found, the mismatch result SHOULD + be reported to the management plane for further action. The + RECEIVER also SHOULD send the ConfirmDataChannelStatusAck message + which MUST carry all the local end statuses of the requested data + channels to the SENDER. . If the RECEIVER is not able to support or to begin the confirmation procedure, the ConfirmDataChannelStatusNack message MUST be responded with the ERROR_CODE which indicates the reason of rejection. - . The SENDER receives the response ConfirmDataChannelStatusAck - message, and compares the received data channel statuses at the - remote end with the data channel statuses at the local end. If a - data channel status mismatch is found, the mismatch result SHOULD - be reported to the management plane for further action. - - . The ConfirmDataChannelStatus message SHOULD be resent, if the - ConfirmDataChannelStatusNack message is received or no response - message is received in the configured time by the SENDER. + . When the SENDER receives the response ConfirmDataChannelStatusAck + message, and MUST compare the received data channel statuses at + the remote end with the data channel statuses at the local end. If + a data channel status mismatch is found, the mismatch result + SHOULD be reported to the management plane for further action. The data channel status mismatch issue identified by LMP may be automatically resolved by RSVP restart. For example, the restarting node may also have damaged its data plane. This leaves the data channels mismatched. But RSVP restart will re-install the data plane state in the restarting node. The issue may also be resolved via RSVP soft state timeout. If the ConfirmDataChannelStatus message is not recognized by the RECEIVER, the RECEIVER ignores this message, and will not send out an acknowledgment message to the SENDER. Due to message loss problem, the SENDER may not be able to receive the acknowledgment message. - In the above two cases, if the ConfirmDataChannelStatusAck or - ConfirmDataChannelStatusNack message is not received by the SENDER - within the configured time, the SENDER SHOULD terminate the data - channel confirmation procedure. A default value of 1 minute is - suggested for this timer. + ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable + transmission mechanisms. If after the retry limit is reached, a + ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack + message is not received by the SENDER, the SENDER SHOULD terminate + the data channel confirmation procedure. 6. Security Considerations [RFC4204] describes how LMP messages between peers can be secured, and these measures are equally applicable to the new messages defined in this document. The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were @@ -561,40 +566,37 @@ [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) ", RFC 4203, October 2005 [RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) ", RFC 4205, October 2005 - [G.841] ITU-T "Types and characteristics of SDH network - protection architectures", October 1998. - 10. Authors' Addresses Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-70230 Email: danli@huawei.com + Huiying Xu Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-72910 Email: xuhuiying@huawei.com - Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129 China Phone: +86 755-289-72912 Email: zhangfatai@huawei.com Snigdho C. Bardalai Fujitsu Network Communications