draft-ietf-ccamp-confirm-data-channel-status-01.txt   draft-ietf-ccamp-confirm-data-channel-status-02.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Huawei Huawei
Snigdho Bardalai Snigdho Bardalai
Fujitsu Fujitsu
Julien Meuric Julien Meuric
France Telecom France Telecom
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Internet Draft Internet Draft
Category: Standards Track Category: Standards Track
Expires: April 2009 October 30, 2008 Expires: May 2009 November 3, 2008
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-01.txt draft-ietf-ccamp-confirm-data-channel-status-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 11, line 12 skipping to change at page 11, line 12
The data channel status mismatch results MAY be stored, and this The data channel status mismatch results MAY be stored, and this
information MAY be queried in the future. information MAY be queried in the future.
The data channel status mismatch issue warned about by LMP may be The data channel status mismatch issue warned about by LMP may be
automatically resolved by RSVP restart. For example, the restarting automatically resolved by RSVP restart. For example, the restarting
node may also have damaged its data plane. This leaves the data node may also have damaged its data plane. This leaves the data
channels mismatched. But RSVP restart will re-install the data plane channels mismatched. But RSVP restart will re-install the data plane
state in the restarting node. state in the restarting node.
If the ConfirmDataChannelStatus message is not recognized by the If the ConfirmDataChannelStatus message is not recognized by the
RECEIVER, and the RECEIVER may not send out an acknowledgement RECEIVER, the RECEIVER will not send out an acknowledgement message
message to the SENDER. In this case, if the to the SENDER. In this case, if the ConfirmDataChannelStatusAck or
ConfirmDataChannelStatusAck or ConfirmDataChannelStatusNack message ConfirmDataChannelStatusNack message is not received by the SENDER
is not received by the SENDER within the configured time, the SENDER within the configured time, the SENDER SHOULD terminate the data
SHOULD terminate the data channel confirmation procedure. A default channel confirmation procedure. A default value of 1 minutes is
value of 1 minutes is suggested for this timer. suggested for this timer.
6. Security Considerations 6. Security Considerations
[RFC4204] describes how LMP messages between peers can be secured, [RFC4204] describes how LMP messages between peers can be secured,
and these measures are equally applicable to the new messages defined and these measures are equally applicable to the new messages defined
in this document. in this document.
The operation of the procedures described in this document does not The operation of the procedures described in this document does not
of themselves constitute a security risk since they do not cause any of themselves constitute a security risk since they do not cause any
change in network state. It would be possible, if the messages were change in network state. It would be possible, if the messages were
skipping to change at page 13, line 16 skipping to change at page 13, line 16
Multi-Protocol Label Switching (GMPLS)", RFC 4205, Multi-Protocol Label Switching (GMPLS)", RFC 4205,
October 2005 October 2005
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 P.R.China Shenzhen 518129 P.R.China
Phone: +86 755-289-71184 Phone: +86 755-289-70230
Email: danli@huawei.com Email: danli@huawei.com
Huiying Xu Huiying Xu
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base, F3-5-B R&D Center, Huawei Base,
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86 755-289-72909 Phone: +86 755-289-72909
Email: xuhuiying@huawei.com Email: xuhuiying@huawei.com
skipping to change at page 14, line 6 skipping to change at page 14, line 6
Snigdho C. Bardalai Snigdho C. Bardalai
Fujitsu Network Communications Fujitsu Network Communications
2801 Telecom Parkway, 2801 Telecom Parkway,
Richardson, Texas 75082 Richardson, Texas 75082
United States of America United States of America
Phone: +1 972 479 2951 Phone: +1 972 479 2951
Email: snigdho.bardalai@us.fujitsu.com Email: snigdho.bardalai@us.fujitsu.com
Julien Meuric Julien Meuric
France Telecom France Telecom
Orange Labs
2, avenue Pierre Marzin 2, avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Phone: +33 2 96 05 28 28 Phone: +33 2 96 05 28 28
Email: julien.meuric@orange-ftgroup.com Email: julien.meuric@orange-ftgroup.com
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A 16153 Via A. Negrone 1/A 16153
 End of changes. 5 change blocks. 
9 lines changed or deleted 10 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/