draft-ietf-ccamp-confirm-data-channel-status-05.txt   draft-ietf-ccamp-confirm-data-channel-status-06.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 25, 2009 Expires: February 2010 August 14, 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-05.txt draft-ietf-ccamp-confirm-data-channel-status-06.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 10, line 32 skipping to change at page 10, line 32
4.4. Backward Compatibility 4.4. Backward Compatibility
Some nodes running in the network may only support the LMP Message 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 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 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 document can not be recognized by these nodes. The unknown message
behavior is not being specified in [RFC4204], it's suggested to behavior is not being specified in [RFC4204], it's suggested to
discard the unknown message silently. This document's defined discard the unknown message silently. This document's defined
mechanisms presume a certain non-standard behavior of existing/non- mechanisms presume a certain non-standard behavior of existing/non-
document supporting nodes. document supporting nodes. To use this mechanisms all nodes MUST have
the extensions described in this document for compatibility.
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
skipping to change at page 12, line 26 skipping to change at page 12, line 26
7.1. LMP Message Types 7.1. LMP Message Types
IANA maintains the "Link Management Protocol (LMP)" registry which IANA maintains the "Link Management Protocol (LMP)" registry which
has a subregistry called "LMP Message Type". IANA is requested to has a subregistry called "LMP Message Type". IANA is requested to
make three new allocations from this registry as follows. The message make three new allocations from this registry as follows. The message
type values are suggested and to be confirmed by IANA. type values are suggested and to be confirmed by IANA.
Value Description Value Description
------ --------------------------------- ------ ---------------------------------
21 ConfirmDataChannelStatus 32 ConfirmDataChannelStatus
22 ConfirmDataChannelStatusAck 33 ConfirmDataChannelStatusAck
23 ConfirmDataChannelStatusNack 34 ConfirmDataChannelStatusNack
7.2. LMP Data Link Object Subobject 7.2. LMP Data Link Object Subobject
IANA maintains the "Link Management Protocol (LMP)" registry which IANA maintains the "Link Management Protocol (LMP)" registry which
has a subregistry called "LMP Object Class name space and Class type has a subregistry called "LMP Object Class name space and Class type
(C-Type)". This subregistry has an entry for the DATA_LINK object, (C-Type)". This subregistry has an entry for the DATA_LINK object,
and there is a further embedded registry called "DATA_LINK Sub-object and there is a further embedded registry called "DATA_LINK Sub-object
Class name space". IANA is requested to make the following allocation Class name space". IANA is requested to make the following allocation
from this embedded registry. The value shown is suggested and to be from this embedded registry. The value shown is suggested and to be
confirmed by IANA. confirmed by IANA.
 End of changes. 4 change blocks. 
6 lines changed or deleted 7 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/