--- 1/draft-ietf-ccamp-confirm-data-channel-status-08.txt 2009-12-14 09:12:41.000000000 +0100 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-09.txt 2009-12-14 09:12:41.000000000 +0100 @@ -1,71 +1,71 @@ Network Working Group D. Li Internet Draft H. Xu Category: Standards Track Huawei S. Bardalai Fujitsu J. Meuric France Telecom D. Caviglia Ericsson -Expires: May 2010 November 10, 2009 +Expires: June 2010 December 14, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-08.txt + draft-ietf-ccamp-confirm-data-channel-status-09.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. + 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 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. As LMP is - already used to verify data plane connectivity, it is considered to - be an appropriate candidate to support this feature. + the location of stranded resources by allowing adjacent Label- + Switching Routers (LSRs) to confirm data channel statuses, and + provides triggers for 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. 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. Failed Resources........................................5 + 2.3. 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 4.3. Message Construction...................................10 4.4. Backward Compatibility.................................10 5. Procedures..................................................10 @@ -102,24 +102,24 @@ 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. + channel for a new Label Switched Path (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. 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 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. @@ -204,31 +203,32 @@ 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 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. + prevent state discrepancies between LSRs. Resource ReserVation + Protocol-Traffic Engineering (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. 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 @@ -287,32 +287,29 @@ The message formats in the sections that follow use Backus-Naur Form (BNF) encoding as defined in [RFC5511]. 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]. - - Three new messages are defined to check data channel status. Message - Type numbers are found in Section 7.1. + 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]. - 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. + Three new messages are defined to check data channel status: + ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, + ConfirmDataChannelStatusNack, which are described in detail in the + following sections. 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 data channel. ::= @@ -322,20 +319,25 @@ 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 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. + 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.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 @@ -401,25 +403,26 @@ 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 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. + 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]. 4.3. Message Construction @@ -435,61 +438,62 @@ In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD be used to identify each timeslot of the data link. 4.4. Backward Compatibility Some nodes running in the network may only support the LMP Message Types, which are already defined in [RFC4204]. The three new types of LMP message defined in this document can not be recognized by these nodes. The unknown message behavior is not being specified in [RFC4204], it's suggested to discard the unknown message silently. - This document's defined mechanisms presume a certain non-standard - behavior of existing/non-document supporting nodes. To use this - mechanisms all nodes MUST have the extensions described in this + The mechanism defined in this document presumes a certain non- + standard behavior of existing/non-document supporting nodes. To use + this mechanism all nodes MUST have the extensions described in this document for compatibility. 5. Procedures - 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: + Adjacent nodes MAY send data channel status confirmation related LMP + messages. Periodical timers or some other events requesting the + confirmation of channel status for the data link may trigger these + messages. It's a local policy decision to start the data channel + status confirmation process. The procedure is described below: - . The SENDER constructs a ConfirmDataChannelStatus message which - 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. + . Initially, the SENDER constructs a ConfirmDataChannelStatus + message which 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 MUST extract the data channel statuses from the + . Upon reception of a ConfirmDataChannelStatus message, 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. - . 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. + . Upon reception of a ConfirmDataChannelStatusAck message, the + SENDER 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 @@ -653,22 +657,22 @@ Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 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 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 + 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