--- 1/draft-ietf-ccamp-confirm-data-channel-status-07.txt 2009-11-10 10:12:27.000000000 +0100 +++ 2/draft-ietf-ccamp-confirm-data-channel-status-08.txt 2009-11-10 10:12:27.000000000 +0100 @@ -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: March 2010 September 3, 2009 +Expires: May 2010 November 10, 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol - draft-ietf-ccamp-confirm-data-channel-status-07.txt + draft-ietf-ccamp-confirm-data-channel-status-08.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. @@ -62,50 +62,50 @@ 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 - 6. Security Considerations.....................................11 + 6. Security Considerations.....................................12 7. IANA Considerations.........................................12 7.1. LMP Message Types......................................12 7.2. LMP Data Link Object Subobject.........................12 - 8. Acknowledgments.............................................12 + 8. Acknowledgments.............................................13 9. References..................................................13 9.1. Normative References...................................13 9.2. Informative References.................................13 - 10. Authors' Addresses.........................................13 + 10. Authors' Addresses.........................................14 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). 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 + advertised by the routing protocols [RFC4203], [RFC5307]. 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 @@ -278,20 +278,23 @@ 4. Extensions to LMP A control plane tool to detect and isolate data channel mismatches is provided in this document by simple additions to the Link Management Protocol (LMP) [RFC4204]. It can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses. Outline procedures are described in this section. More detailed procedures are found in Section 5. + 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]. @@ -410,21 +413,21 @@ 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. + 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. @@ -554,20 +557,24 @@ 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. + [RFC5511] A. Farrel, Ed., "Routing Backus-Naur Form (RBNF): A + Syntax Used to Form Encoding Rules in Various Routing + Protocol Specifications", RFC 5511, April 2009. + 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 @@ -576,24 +583,28 @@ 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 + [RFC4606] E. Mannie, Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Extensions for Synchronous Optical + Network (SONET) and Synchronous Digital Hierarchy (SDH) + Control", RFC 4606, August 2006 + + [RFC5307] K. Kompella, Ed., "IS-IS Extensions in Support of + Generalized Multi-Protocol Label Switching (GMPLS)", RFC + 5307, October 2008 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