draft-ietf-ccamp-confirm-data-channel-status-07.txt   draft-ietf-ccamp-confirm-data-channel-status-08.txt 
Network Working Group D. Li Network Working Group D. Li
Internet Draft H. Xu Internet Draft H. Xu
Category: Standards Track Huawei Category: Standards Track Huawei
S. Bardalai S. Bardalai
Fujitsu Fujitsu
J. Meuric J. Meuric
France Telecom France Telecom
D. Caviglia D. Caviglia
Ericsson Ericsson
Expires: March 2010 September 3, 2009 Expires: May 2010 November 10, 2009
Data Channel Status Confirmation Extensions Data Channel Status Confirmation Extensions
for the Link Management Protocol 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3. Motivation...................................................6 3. Motivation...................................................6
4. Extensions to LMP............................................7 4. Extensions to LMP............................................7
4.1. Confirm Data Channel Status Messages....................7 4.1. Confirm Data Channel Status Messages....................7
4.1.1. ConfirmDataChannelStatus Messages..................7 4.1.1. ConfirmDataChannelStatus Messages..................7
4.1.2. ConfirmDataChannelStatusAck Messages...............8 4.1.2. ConfirmDataChannelStatusAck Messages...............8
4.1.3. ConfirmDataChannelStatusNack Messages..............8 4.1.3. ConfirmDataChannelStatusNack Messages..............8
4.2. Data Channel Status Subobject...........................9 4.2. Data Channel Status Subobject...........................9
4.3. Message Construction...................................10 4.3. Message Construction...................................10
4.4. Backward Compatibility.................................10 4.4. Backward Compatibility.................................10
5. Procedures..................................................10 5. Procedures..................................................10
6. Security Considerations.....................................11 6. Security Considerations.....................................12
7. IANA Considerations.........................................12 7. IANA Considerations.........................................12
7.1. LMP Message Types......................................12 7.1. LMP Message Types......................................12
7.2. LMP Data Link Object Subobject.........................12 7.2. LMP Data Link Object Subobject.........................12
8. Acknowledgments.............................................12 8. Acknowledgments.............................................13
9. References..................................................13 9. References..................................................13
9.1. Normative References...................................13 9.1. Normative References...................................13
9.2. Informative References.................................13 9.2. Informative References.................................13
10. Authors' Addresses.........................................13 10. Authors' Addresses.........................................14
11. Full Copyright Statement...................................15 11. Full Copyright Statement...................................15
12. Intellectual Property Statement............................15 12. Intellectual Property Statement............................15
13. Disclaimer of Validity.....................................16 13. Disclaimer of Validity.....................................16
1. Introduction 1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) networks are Generalized Multiprotocol Label Switching (GMPLS) networks are
constructed from Traffic Engineering (TE) links connecting Label constructed from Traffic Engineering (TE) links connecting Label
Switching Routers (LSRs). The TE links are constructed from a set of Switching Routers (LSRs). The TE links are constructed from a set of
data channels. In this context, a data channel corresponds to a data channels. In this context, a data channel corresponds to a
resource label in a non-packet technology (such as a timeslot or a resource label in a non-packet technology (such as a timeslot or a
lambda). lambda).
A data channel status mismatch exists if the LSR at one end of a TE 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 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" 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 means cross-connected or bound to an end-point for the receipt or
delivery of data. delivery of data.
Data channel mismatches cannot be detected from the TE information 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 existence of some data channel mismatch problems may be detected by
a mismatch in the advertised bandwidths where bidirectional TE links a mismatch in the advertised bandwidths where bidirectional TE links
and bidirectional services are in use, but where unidirectional and bidirectional services are in use, but where unidirectional
services exist, or where multiple data channel mismatches occur, it services exist, or where multiple data channel mismatches occur, it
is not possible to detect such errors through the routing protocol- is not possible to detect such errors through the routing protocol-
advertised TE information. In any case, there is no mechanism to advertised TE information. In any case, there is no mechanism to
isolate the mismatches by determining which data channels are at isolate the mismatches by determining which data channels are at
fault. fault.
If a data channel mismatch exists, any attempt to use the data If a data channel mismatch exists, any attempt to use the data
skipping to change at page 7, line 15 skipping to change at page 7, line 15
4. Extensions to LMP 4. Extensions to LMP
A control plane tool to detect and isolate data channel mismatches is A control plane tool to detect and isolate data channel mismatches is
provided in this document by simple additions to the Link Management provided in this document by simple additions to the Link Management
Protocol (LMP) [RFC4204]. It can assist in the location of stranded Protocol (LMP) [RFC4204]. It can assist in the location of stranded
resources by allowing adjacent LSRs to confirm data channel statuses. resources by allowing adjacent LSRs to confirm data channel statuses.
Outline procedures are described in this section. More detailed Outline procedures are described in this section. More detailed
procedures are found in Section 5. 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 4.1. Confirm Data Channel Status Messages
Extensions to LMP to confirm a data channel status are described Extensions to LMP to confirm a data channel status are described
below. In order to confirm a data channel status, the new LMP below. In order to confirm a data channel status, the new LMP
messages are sent between adjacent nodes periodically or driven by messages are sent between adjacent nodes periodically or driven by
some event (such as an operator command, a configurable timer, or the some event (such as an operator command, a configurable timer, or the
rejection of an LSP setup message because of an unavailable rejection of an LSP setup message because of an unavailable
resource). The new LMP messages run over the control channel, resource). The new LMP messages run over the control channel,
encapsulated in UDP with an LMP port number and IP addressing as encapsulated in UDP with an LMP port number and IP addressing as
defined in Link Management Protocol (LMP) [RFC4204]. defined in Link Management Protocol (LMP) [RFC4204].
skipping to change at page 10, line 8 skipping to change at page 10, line 13
the length of the subobject up to, but not including, the first byte the length of the subobject up to, but not including, the first byte
of padding. Thus, the amount of padding is deduced and not of padding. Thus, the amount of padding is deduced and not
represented in the Length field. represented in the Length field.
Note that the Data Channel ID is given in the context of the sender Note that the Data Channel ID is given in the context of the sender
of the ConfirmChannelStatus message. of the ConfirmChannelStatus message.
The data-channel ID must be encoded as a label value. Based on the 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 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 used will be different. For SONET/SDH the label value is encoded as
per RFC4606. per [RFC4606].
4.3. Message Construction 4.3. Message Construction
Data_Link Class is included in ConfirmDataChannelStatus and Data_Link Class is included in ConfirmDataChannelStatus and
ConfirmDataChannelStatusAck messages, which is defined in section ConfirmDataChannelStatusAck messages, which is defined in section
13.12 in [RFC4204]. 13.12 in [RFC4204].
The status of the TE link end MUST be carried by the Data Channel 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. Status subobject which is defined in section 4.2 of this document.
The new subobject MUST be part of Data_Link Class. The new subobject MUST be part of Data_Link Class.
skipping to change at page 13, line 15 skipping to change at page 13, line 24
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005. 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 9.2. Informative References
[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) -- [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September Version 1 Functional Specification", RFC 2205, September
1997 1997
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001 RFC 3209, December 2001
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003 3473, January 2003
[RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP [RFC5063] A. Satyanarayana, R. Rahman, "Extensions to GMPLS RSVP
Graceful Restart", RFC 5063, September 2007 Graceful Restart", RFC 5063, September 2007
[RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of [RFC4203] K. Kompella, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS) ", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4203, October 2005 4203, October 2005
[RFC4205] K. Kompella, Ed., "Intermediate System to Intermediate [RFC4606] E. Mannie, Ed., "Generalized Multi-Protocol Label
System (IS-IS) Extensions in Support of Generalized Switching (GMPLS) Extensions for Synchronous Optical
Multi-Protocol Label Switching (GMPLS) ", RFC 4205, Network (SONET) and Synchronous Digital Hierarchy (SDH)
October 2005 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 10. Authors' Addresses
Dan Li Dan Li
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Shenzhen 518129 China Shenzhen 518129 China
Phone: +86 755-289-70230 Phone: +86 755-289-70230
Email: danli@huawei.com Email: danli@huawei.com
 End of changes. 11 change blocks. 
12 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/