--- 1/draft-ietf-ccamp-attribute-bnf-00.txt 2011-05-13 00:15:31.000000000 +0200 +++ 2/draft-ietf-ccamp-attribute-bnf-01.txt 2011-05-13 00:15:31.000000000 +0200 @@ -1,20 +1,20 @@ Internet Draft Lou Berger (LabN) Updates: 4875, 5420, [NO-PHP-OOB] Category: Standards Track George Swallow (Cisco) -Expiration Date: May 9, 2011 +Expiration Date: November 11, 2011 - November 9, 2010 + May 11, 2011 LSP Attributes Related Routing Backus-Naur Form - draft-ietf-ccamp-attribute-bnf-00.txt + draft-ietf-ccamp-attribute-bnf-01.txt Abstract Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form, and clarifies related Resv message formats. @@ -33,25 +33,25 @@ 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on May 9, 2011 + This Internet-Draft will expire on November 11, 2011 Copyright and License Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -60,26 +60,26 @@ Table of Contents 1 Introduction ........................................... 2 1.1 Conventions Used In This Document ...................... 3 2 Path Messages .......................................... 3 2.1 Path Message Format .................................... 4 3 Resv Messages .......................................... 4 3.1 Resv Message Format -- Per LSP Operational Status ...... 5 3.2 Resv Message Format -- Per S2L Operational Status ...... 6 3.2.1 Compatibility .......................................... 6 - 4 Security Considerations ................................ 6 + 4 Security Considerations ................................ 7 5 IANA Considerations .................................... 7 6 Acknowledgments ........................................ 7 7 References ............................................. 7 7.1 Normative References ................................... 7 - 7.2 Informative References ................................. 7 + 7.2 Informative References ................................. 8 8 Authors' Addresses ..................................... 8 1. Introduction Signaling in support of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling support for point-to-multipoint (P2MP) TE LSPs. Two LSP Attributes related objects are defined in [RFC5420]. These @@ -190,34 +190,40 @@ allows for LSP attributes object to be modified using make-before- break, see RFC3209. This definition is sufficient for point-to-point ([RFC3209] and [RFC3473]) LSPs, and the special case where all point- to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the same operational status (as used in [RFC5420]). But, this definition does not allow for different egress LSRs to report different report operational status. In order to allow such reporting, this document adds the following definition: An LSR that wishes to report operational status of a (point-to- - multipoint) S2L sub-LSP may include the LSP_ATTRIBUTES object in a - Resv message, or update the object that is already carried in a - Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP + multipoint) S2L sub-LSP, it may include the LSP_ATTRIBUTES object + in a Resv message, or update the object that is already carried in + a Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP status MUST follow a S2L_SUB_LSP object. Only the first instance of the LSP_ATTRIBUTES object is meaningful within the context of a S2L_SUB_LSP object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged. When an LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP object, the LSP_ATTRIBUTES object represents the - operational status of the whole point-to-multipoint LSP. - Subsequent instances of the object SHOULD be ignored and MUST be - forwarded unchanged. Relative object positioning SHOULD be - preserved. + operational status of all S2L sub-LSPs identified in the message. + Subsequent instances of the object (e.g, in the filter spec or the + S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be + forwarded unchanged. When a branch node is combining Resv state + from multiple receivers into a single Resv message and an + LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP + object in a received Resv message, the received LSP_ATTRIBUTES + object SHOULD be moved to follow the first received S2L_SUB_LSP + object, and then SHOULD be duplicated for, and placed after, each + subsequent S2L_SUB_LSP object. 3.1. Resv Message Format -- Per LSP Operational Status This section presents the Resv message format for LSPs as modified by [RFC5420], and can be used to report operational status per LSP. Unmodified formats are not listed. This following is based on [RFC4875]. ::= [ ] @@ -332,11 +338,11 @@ Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net George Swallow Cisco Systems, Inc. Email: swallow@cisco.com -Generated on: Tue Nov 9 13:46:47 CST 2010 +Generated on: Wed, May 11, 2011 6:02:06 PM