--- 1/draft-ietf-ccamp-confirm-data-channel-status-00.txt 2008-10-30 06:12:03.000000000 +0100 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-01.txt 2008-10-30 06:12:03.000000000 +0100 @@ -3,130 +3,130 @@ Huawei Snigdho Bardalai Fujitsu Julien Meuric France Telecom Diego Caviglia Ericsson Internet Draft Category: Standards Track -Expires: September 2008 March 27, 2008 +Expires: April 2009 October 30, 2008 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-00.txt + draft-ietf-ccamp-confirm-data-channel-status-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. - 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." + 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 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. + 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. 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.3. Manual Change of the Cross-Connection State.............6 2.4. Failed Resources........................................6 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 5. Procedures..................................................10 6. Security Considerations.....................................11 7. IANA Considerations.........................................11 7.1. LMP Message Types......................................11 - 7.2. LMP Data Link Object Subobject.........................11 + 7.2. LMP Data Link Object Subobject.........................12 8. Acknowledgments.............................................12 9. References..................................................12 9.1. Normative References...................................12 9.2. Informative References.................................12 10. Author's Addresses.........................................13 11. Full Copyright Statement...................................14 12. Intellectual Property Statement............................14 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). + 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). A data channel status mismatch exists if the LSR at one end of a TE link believes that the data channel is assigned to carry data, but the LSR at the other end does not. The term "ready to carry data" means cross-connected or bound to an end-point for the receipt or delivery of data. Data channel mismatches cannot be detected from the TE information advertised by the routing protocols [RFC4203], [RFC4205]. The existence of some data channel mismatch problems may be detected by a mismatch in the advertised bandwidths where bidirectional TE links and bidirectional services are in use, but where unidirectional services exist, or where multiple data channel mismatches occur, it is not possible to detect such errors through the routing protocol- advertised TE information. In any case, there is no mechanism to isolate the mismatches by determining which data channels are at fault. If a data channel mismatch exists, any attempt to use the data channel for a new LSP will fail. One end of the TE link may attempt - to assign the TE link for use, but the other end will report the data - channel as unavailable when the control plane or management plane - attempts to assign it to an LSP. + to assign the TE link for use, but the other end will report the + data channel as unavailable when the control plane or management + plane attempts to assign it to an LSP. Although such a situation can be resolved through the use of the Acceptable Label Set object in GMPLS signaling [RFC3473], such a - procedure is inefficient since it may require an additional signaling - exchange for each LSP that is set up. When many LSPs are to be set - up, and when there are many data channel mismatches, such + procedure is inefficient since it may require an additional + signaling exchange for each LSP that is set up. When many LSPs are + to be set up, and when there are many data channel mismatches, such inefficiencies become significant. It is desirable to avoid the additional signaling overhead, and to report the problems to the management plane so that they can be resolved to improve the efficiency of LSP setup. Correspondingly, such a mismatch situation may give rise to misconnections in the data plane especially when LSPs are set up using management plane operations. Resources (data channels) that are in a mismatched state are often @@ -160,23 +160,23 @@ So it is desirable to confirm the data channel statuses as early as possible. 2.1. Mismatch Caused by Manual Configuration The operator may have configured a cross-connect at only one end of a TE link using an EMS. The resource at one end of the data channel is allocated, but the corresponding resource is still available at the other end of the same data channel. In this case, the data - channel may appear to be available for use by the control plane - when viewed from one end of the TE link, but will be considered to - be unavailable by the other end of the TE link. Alternatively, the + channel may appear to be available for use by the control plane when + viewed from one end of the TE link, but will be considered to be + unavailable by the other end of the TE link. Alternatively, the available end of the data channel may be cross-connected by the management plane and a misconnection may result from the fact that the other end of the data channel is already cross-connected. Figure 1 shows a data channel between nodes A and B. The resource at A's end of the TE link is allocated through manual configuration, while the resource at B's end of the TE link available, so the data channel status is mismatched. allocated available @@ -215,37 +215,37 @@ state after the expiry of the Recovery Timer. It is a local policy decision how this mismatched state is handled. 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-Connect State +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, red-line, etc. These operations will make it impossible to release the cross-connect when an LSP is being deleted. 2.4. 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. + 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. + This mismatch in the termination point status can lead to failure + in case of bidirectional LSP set-up. Good Failed +-+------------+-+ A | | |X| B +-+------------+-+ data channel Path Message with Upstream Label----> Figure 3. Mismatch caused by resource failure @@ -286,22 +286,21 @@ Outline procedures are described in this section. More detailed procedures are found in Section 5. 4.1. Confirm Data Channel Status Messages 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). + rejection of an LSP setup message because of an unavailable resource). Three new messages are defined to check data channel status. Message Type numbers are found in Section 7.1. 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 @@ -353,21 +352,21 @@ Procedure not supported" MUST be sent. If the data channel status confirmation procedure is supported, but the node is unable to begin the procedure, a ConfirmDataChannelStatusNack message containing an ERROR_CODE indicating "Unwilling to Confirm" MUST be sent. If a ConfirmDataChannelStatusNack message is received with such an ERROR_CODE, the node which originated the ConfirmDataChannelStatus message MAY schedule the ConfirmDataChannelStatus message retransmission after a configured time. A default value of 10 minutes - is RECOMMENDED for this timer. + is suggested for this timer. ::= [] The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being rejected. 4.2. Data Channel Status Subobject @@ -393,25 +392,25 @@ This is a series of bit flags to indicate the status of the data channel. The following values are defined. 0x0000 : The channel is available/free. 0x0001 : The channel is cross-connected/allocated. Data Channel ID This identifies the data channel. The length of this field can be deduced from the Length field in the subobject. Note that all - subobjects must be padded to a four byte boundary with trailing - zeros. If such padding is required, the Length field MUST indicate - the length of the subobject up to, but not including, the first - byte of padding. Thus, the amount of padding is deduced and not - represented in the Length field. + subobjects must be padded to a four byte boundary with trailing zeros. + If such padding is required, the Length field MUST indicate the + length of the subobject up to, but not including, the first byte of + padding. Thus, the amount of padding is deduced and not represented + 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. 5. Procedures @@ -455,20 +454,28 @@ The data channel status mismatch results MAY be stored, and this information MAY be queried in the future. The data channel status mismatch issue warned about 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. + If the ConfirmDataChannelStatus message is not recognized by the + RECEIVER, and the RECEIVER may not send out an acknowledgement + message to the SENDER. In this case, 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 minutes is suggested for this timer. + 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 intercepted or spoofed to cause bogus alerts in the management plane @@ -502,22 +509,22 @@ Class name space". IANA is requested to make the following allocation from this embedded registry. The value shown is suggested and to be confirmed by IANA. Value Description ------ --------------------------------- 9 Data Channel Status 8. Acknowledgments - We would like to thank Adrian Farrel and Dimitri Papadimitriou for - their useful comments. + We would like to thank Adrian Farrel, Dimitri Papadimitriou for their + useful comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. @@ -528,57 +535,53 @@ Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP Graceful Restart", RFC 5063, September 2007 [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 -10. Author's Addresses +10. Authors' Addresses Dan Li - Huawei Technologies Co., Ltd. + Huawei Technologies F3-5-B R&D Center, Huawei Base, - Bantian, Longgang District Shenzhen 518129 P.R.China - Phone: +86-755-28973237 + Phone: +86 755-289-71184 Email: danli@huawei.com Huiying Xu - Huawei Technologies Co., Ltd. + Huawei Technologies F3-5-B R&D Center, Huawei Base, - Bantian, Longgang District Shenzhen 518129 P.R.China - Phone: +86-755-28972909 + Phone: +86 755-289-72909 Email: xuhuiying@huawei.com Fatai Zhang - Huawei Technologies Co., Ltd. + Huawei Technologies F3-5-B R&D Center, Huawei Base, - Bantian, Longgang District Shenzhen 518129 P.R.China - Phone: +86-755-28979791 + Phone: +86 755-28979791 Email: zhangfatai@huawei.com Snigdho C. Bardalai - Fujitsu Network Communications, Inc. + Fujitsu Network Communications 2801 Telecom Parkway, Richardson, Texas 75082 United States of America Phone: +1 972 479 2951 Email: snigdho.bardalai@us.fujitsu.com Julien Meuric France Telecom 2, avenue Pierre Marzin 22307 Lannion Cedex