draft-ietf-ccamp-confirm-data-channel-status-04.txt   draft-ietf-ccamp-confirm-data-channel-status-05.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: November 2009 May 22, 2009 Expires: November 2009 May 25, 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-04.txt draft-ietf-ccamp-confirm-data-channel-status-05.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 Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.2. Mismatch Caused by LSP Deletion.........................5 2.2. Mismatch Caused by LSP Deletion.........................5
2.3. Failed Resources........................................5 2.3. Failed Resources........................................5
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
5. Procedures..................................................10 5. Procedures..................................................10
6. Security Considerations.....................................11 6. Security Considerations.....................................11
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.............................................12
9. References..................................................12 9. References..................................................13
9.1. Normative References...................................12 9.1. Normative References...................................13
9.2. Informative References.................................13 9.2. Informative References.................................13
10. Authors' Addresses.........................................13 10. Authors' Addresses.........................................13
11. Full Copyright Statement...................................14 11. Full Copyright Statement...................................15
12. Intellectual Property Statement............................15 12. Intellectual Property Statement............................15
13. Disclaimer of Validity.....................................15 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).
skipping to change at page 10, line 23 skipping to change at page 10, line 23
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.
In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD In the case of SDH/SONET, DATA Channel ID in the new subobject SHOULD
be used to identify each timeslot of the data link. 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.
5. Procedures 5. Procedures
The data channel status confirmation related LMP messages MAY be sent The data channel status confirmation related LMP messages MAY be sent
between adjacent nodes which are triggered by timer periodically or between adjacent nodes which are triggered by timer periodically or
driven by some events to confirm the channel status for the data 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 links. It's a local police decision to start the data channel status
confirmation process. The procedure is described below: confirmation process. The procedure is described below:
. The SENDER constructs a ConfirmDataChannelStatus message which . The SENDER constructs a ConfirmDataChannelStatus message which
MUST contain one or more DATA_LINK objects. DATA_LINK object is MUST contain one or more DATA_LINK objects. DATA_LINK object is
 End of changes. 7 change blocks. 
6 lines changed or deleted 18 lines changed or added

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