--- 1/draft-ietf-ccamp-confirm-data-channel-status-06.txt 2009-09-04 11:12:10.000000000 +0200 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-07.txt 2009-09-04 11:12:10.000000000 +0200 @@ -1,35 +1,36 @@ Network Working Group D. Li Internet Draft H. Xu Category: Standards Track Huawei S. Bardalai Fujitsu J. Meuric France Telecom D. Caviglia Ericsson -Expires: February 2010 August 14, 2009 +Expires: March 2010 September 3, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-06.txt + draft-ietf-ccamp-confirm-data-channel-status-07.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 @@ -282,24 +283,24 @@ 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]. + 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. 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 @@ -396,25 +397,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 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 @@ -426,28 +427,28 @@ 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. 4.4. Backward Compatibility Some nodes running in the network may only support the LMP Message - Type from 1 to 20, which are already defined in [RFC4204]. The three - new types of LMP message (Message Type from 21 to 23) 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 document for compatibility. + 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 + 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: . The SENDER constructs a ConfirmDataChannelStatus message which @@ -640,22 +641,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