--- 1/draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt 2010-01-13 18:10:52.000000000 +0100 +++ 2/draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt 2010-01-13 18:10:52.000000000 +0100 @@ -1,24 +1,24 @@ CCAMP Working Group D. Caviglia Internet-Draft D. Ceccarelli Intended status: Standards Track D. Bramanti -Expires: July 12, 2010 Ericsson +Expires: July 17, 2010 Ericsson D. Li Huawei Technologies S. Bardalai Fujitsu Network - January 08, 2010 + January 13, 2010 RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. - draft-ietf-ccamp-pc-spc-rsvpte-ext-05 + draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Abstract In a transport network scenario, where Data Plane connections are controlled either by a Generalized Multi-Protocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. The requirements for the @@ -48,21 +48,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 12, 2010. + This Internet-Draft will expire on July 17, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -206,36 +206,37 @@ The ingress MUST check that no corresponding Path state exists and that corresponding Data Plane state does exist. If there is an error, this MUST be reported to the operator and further protocol action MUST NOT be taken. The ingress signals the LSP using a Path message with the H bit and R bit set in the ADMIN_STATUS object. In this mode of handover, the Path message also carries an ERO that includes Label subobjects indicating the labels used by the LSP at each hop. The ingress MUST start the Expiration timer (see Section 4.2.1.2 for expiration of - this timer). Such timer SHOULD be configurable per LSP. + this timer). Such timer SHOULD be configurable per LSP and have a + default value of 30 seconds. Each LSR that receives a Path message with the H bit set checks to see whether there is any matching Path state. - If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473]. - If matching Path state is found with the H bit clear, this is an error and MUST be treated according to the error case description - in Section 4.2.xx + in Section 4.2.1.1 - If no Path state is found, the LSR goes on to check whether there is any matching Data Plane state. - If no matching Data Plane state is found (including only partially matching Data Plane state), this is an error or a race condition. It MUST be handled according to the description in - Section 4.2.xx + Section 4.2.1.1 - If matching Data Plane state is found, the LSR MUST save the Path state (including the set H bit), and MUST forward the Path message to the egress. The LSR MUST retain any MP state associated with the LSP at this point. An egress LSR MUST act as any other LSR, except that there is no downstream node to which to forward the Path message. If all checks are passed, the egress MUST respond with a Resv with the H bit set. A transit LSR MUST process each Resv according to the normal rules of @@ -341,22 +342,22 @@ | Path Tear | Path Tear | Path Tear | |--------------->|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Path Msg and Communication Failure (no reliable delivery) If the Resv message is not received before the expiration of the Expiration timer the handover procedure is aborted as described in Section 4.1. Please note that any node that has forwarded a Path - (LSR A), i.e. has installed local path state, MUST send a PathTear - when that state is removed. + (LSR A), i.e. has installed local path state, will send a PathTear + when that state is removed (accordingly to [RFC2205]). 4.2.2. MP to CP Handover Failure - Resv Error 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure In the case of failure occurrence during the Resv message processing, (in case there has been any change in the data plane during the signaling) the node MUST send a PathErr message in the upstream direction. The PathErr message is constructed and processed as defined above in Section 4.2.1.1. The failure detection node MUST @@ -609,21 +610,22 @@ | | | | | X | | | | | | | | | Ingress LER LSR A LSR B Egress LER Per [RFC 3473] section 7.2.2 the ingress node should wait for a configurable amount of time (30 seconds by default) and then send a PathTear message. In this case the normal deletion procedure MUST NOT be followed. When the Expiration timer elapses a manual - intervention from network operator is requested. + intervention from network operator is requested and normal, i.e., pre + CP to MP handover, LSP processing continues. - CASE II - Resv message and node down | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| | X X---------| | | | | | X | |