--- 1/draft-ietf-ccamp-confirm-data-channel-status-02.txt 2009-05-06 06:12:11.000000000 +0200 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-03.txt 2009-05-06 06:12:11.000000000 +0200 @@ -1,94 +1,91 @@ -Network Working Group Dan Li - Huiying Xu - Huawei - Snigdho Bardalai +Network Working Group D. Li +Internet Draft H. Xu +Category: Standards Track Huawei + S. Bardalai Fujitsu - Julien Meuric + J. Meuric France Telecom - Diego Caviglia + D. Caviglia Ericsson -Internet Draft -Category: Standards Track -Expires: May 2009 November 3, 2008 +Expires: November 2009 May 6, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-02.txt + draft-ietf-ccamp-confirm-data-channel-status-03.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. + 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. + 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 + 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 + 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. 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.............6 + 2.3. Manual Change of the Cross-Connection State.............5 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. 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.................................12 - 10. Author's Addresses.........................................13 - 11. Full Copyright Statement...................................14 - 12. Intellectual Property Statement............................14 + 9.2. Informative References.................................13 + 10. Authors' Addresses.........................................13 + 11. Full Copyright Statement...................................15 + 12. Intellectual Property Statement............................15 + 13. Disclaimer of Validity.....................................16 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). @@ -133,20 +130,22 @@ 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. 2. Problem Explanation Examples of data channel mismatches are described in the following three scenarios. @@ -201,40 +200,41 @@ 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 [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 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. + 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 + 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, - red-line, etc. These operations will make it impossible to release - the cross-connect when an LSP is being deleted. + 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 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 @@ -243,38 +243,39 @@ Good Failed +-+------------+-+ A | | |X| B +-+------------+-+ data channel Path Message with Upstream Label----> Figure 3. Mismatch caused by resource failure In this case upstream node chooses to use termination point A in - order to receive traffic from downstream node. From the upstream's - point of view, the resource is available thus usable; however, in the - downstream node, the corresponding termination point (resource B) is - broken. This leads to a set-up failure. + order to receive traffic from downstream node. From the upstream + node's point of view, the resource is available thus usable; however, + in the downstream node, the corresponding termination point (resource + B) is broken. This leads to a set-up failure. 3. Motivation The requirement does not come from a lack in GMPLS specifications themselves but rather from operational concerns because, in most cases, GMPLS-controlled networks will co-exist with legacy networks and legacy procedures. - The protocol extensions are intended to detect data plane problems - resulting from mis-use or mis-configurations triggered by user error, - or resulting from failure to clean up the data plane after control - plane disconnection. It is anticipated that human mistake is probably - the major factor to deal with. It is not the intention to provide a - protocol mechanism to deal with broken implementations. + The protocol extensions defined in this document are intended to + detect data plane problems resulting from mis-use or mis- + configurations triggered by user error, or resulting from failure to + clean up the data plane after control plane disconnection. It is + anticipated that human mistake is probably the major source of errors + to deal with. It is not the intention to provide a protocol mechanism + to deal with broken implementations. The procedures defined in this document are designed to be operated on a periodic or on-demand basis. It is NOT RECOMMENDED that the procedures be used to provide a continuous and on-line monitoring process. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. 4. Extensions to LMP @@ -287,20 +288,29 @@ 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). + 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. 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 @@ -309,36 +319,36 @@ ::= [...] When a node receives the ConfirmDataChannelStatus message, and the data channel status confirmation procedure is supported at the node, the node compares its own data channel statuses with all of the data channel statuses sent by the remote end in the ConfirmDataChannelStatus message. If a data channel status mismatch - is found, this mismatch result SHOULD be reported to the management - plane for further action. Management plane reporting procedures and - actions are outside the scope of this document. + is found, this mismatch result is expected to be reported to the + management plane for further action. Management plane reporting + procedures and actions are outside the scope of this document. 4.1.2. ConfirmDataChannelStatusAck Messages The ConfirmDataChannelStatusAck message is sent back to the node which originated the ConfirmDataChannelStatus message to return the requested data channel statuses. When the ConfirmDataChannelStatusAck message is received, the node compares the received data channel statuses at the remote end with those at the local end (the same operation as performed by the receiver of the ConfirmDataChannelStatus message). If a data channel - status mismatch is found, the mismatch result SHOULD be reported to - the management plane for further action. + status mismatch is found, the mismatch result is expected to be + reported to the management plane for further action. ::= [...] The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ConfirmDataChannelStatus message being acknowledged. Note that the ConfirmDataChannelStatusAck message is used both when the data channel statuses match and when they do not match. @@ -386,24 +396,23 @@ // Data Channel ID // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Channel Status: 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. + 0x0001 : The channel is unavailable/in-use. 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. Note that the Data Channel ID is given in the context of the sender of the ConfirmChannelStatus message. @@ -414,26 +423,26 @@ per RFC4606. 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 SENDER constructs a ConfirmDataChannelStatus message which - contains one or more DATA_LINK objects. 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. + 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. . 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. @@ -445,35 +454,38 @@ . 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. - 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 + 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. + 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 will not send out an acknowledgement message - to the SENDER. In this case, if the ConfirmDataChannelStatusAck or + 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 minutes is + channel confirmation procedure. A default value of 1 minute 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 @@ -509,35 +521,43 @@ 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, Dimitri Papadimitriou for their - useful comments. + We would like to thank Adrian Farrel, Dimitri Papadimitriou, Lou + Berger 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. 9.2. Informative References + [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, September + 1997 + + [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. + Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", + RFC 3209, December 2001 + [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 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 @@ -535,115 +555,128 @@ 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 + [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 P.R.China + 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 P.R.China + Shenzhen 518129 China - Phone: +86 755-289-72909 + Phone: +86 755-289-72910 Email: xuhuiying@huawei.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base, - Shenzhen 518129 P.R.China + Shenzhen 518129 China - Phone: +86 755-28979791 + Phone: +86 755-289-72912 Email: zhangfatai@huawei.com Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway, - Richardson, Texas 75082 - United States of America + Richardson, Texas 75082, USA Phone: +1 972 479 2951 Email: snigdho.bardalai@us.fujitsu.com + Julien Meuric - France Telecom - Orange Labs + France Telecom Orange Labs 2, avenue Pierre Marzin - 22307 Lannion Cedex - France + 22307 Lannion Cedex, France Phone: +33 2 96 05 28 28 Email: julien.meuric@orange-ftgroup.com Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 Email: diego.caviglia@ericsson.com 11. Full Copyright Statement - Copyright (C) The IETF Trust (2008). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November 10, + 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. 12. Intellectual Property Statement - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. + The IETF Trust takes no position regarding the validity or scope of + any Intellectual Property Rights or other rights that might be + claimed to pertain to the implementation or use of the technology + described in any IETF Document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. + Copies of Intellectual Property disclosures made to the IETF + Secretariat and any assurances of licenses to be made available, or + the result of an attempt made to obtain a general license or + permission for the use of such proprietary rights by implementers or + users of this specification can be obtained from the IETF on-line IPR + repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + any standard or specification contained in an IETF Document. Please + address the information to the IETF at ietf-ipr@ietf.org. - 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. +13. Disclaimer of Validity - 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". + All IETF Documents and the information contained therein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY + WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. Provisions Relating to IETF Documents in + effect on the date of publication of this document + (http://trustee.ietf.org/license-info). Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document.