Network Working Group P. Champagne Internet-Draft W. Dec Intended status: Informational Cisco Systems Expires: January 3, 2009 S. Wadhwa Juniper Networks S. De Cnodder Alcatel-Lucent R. Maglione Telecom Italia July 2, 2008 Multicast Control Extensions for ANCP draft-ancp-mc-extensions-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 January 3, 2009. Abstract This draft is aimed at describing the ANCP protocol extensions required to support the NAS initiated ANCP Multicast Control use case described in ANCP framework draft. It proposes the definition of new ANCP message types, along with well known TLVs. Champagne, et al. Expires January 3, 2009 [Page 1] Internet-Draft Multicast Control Extensions for ANCP July 2008 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ANCP Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. ANCP Multicast Control Messages . . . . . . . . . . . . . . . 5 4.1. Multicast Replication Control Request Message . . . . . . 5 5. ANCP Multicast Response Messages . . . . . . . . . . . . . . . 12 5.1. Multicast Status Response Message . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Champagne, et al. Expires January 3, 2009 [Page 2] Internet-Draft Multicast Control Extensions for ANCP July 2008 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction This draft is aimed at describing the ANCP protocol extensions required to support the ANCP Multicast Control use case described in ANCP framework draft [ANCPFW] Section 3.4. This proposal aims at collecting feedback from this community in order to work towards consensus and the text derived from this document would be intended to be incorporated in "ANCP Protocol I-D" [ANCPPR]. 3. ANCP Header The format of the ANCP multicast control messages starts with the common GSMP header as in the case of the existing ANCP implementation. Following is the format of this header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result field derived from GSMP [RFC3292] has the following codes: Nack: Res = 0x1 - Renamed result code indicating that no response is expected to the message other than in cases of failuire caused during the processing of the message contents or that of the contained directive(s). Champagne, et al. Expires January 3, 2009 [Page 3] Internet-Draft Multicast Control Extensions for ANCP July 2008 AckAll: Res = 0x2 - Result code indicating that a response to the message is requested in all cases. It is specifically intended to be used in some cases for Request messages only, and is not to be used in Event messages. Success: Res = 0x3 - Allowed to be set in Response Messages only to communicate successful execution of all directives in a previous Request. Failure: Res = 0x4 - Allowed to be set in Response Messages Only to communicate failure of execution of one directives in a previous Request. The Transaction Identifier field is used to distinguish between Request messages and to associate a Response message to a Request. Applications that require such response correlation MUST set the Transaction Identifier to a value in the range (1, 2^24 - 1). When used in this manner, the Transaction Identifier sequencing MUST be maintained independently for each ANCP adjacency and per message type. Furthermore, it SHOULD be incremented linearly for each new message of the given type, cycling back to 1 after running the full range. The transport protocol used by ANCP (TCP currently) guarantees sequenced in order delivery, and thus the reception of a message that does not fit into the expected transaction id sequence can signify a problem with the sender. When such an event is detected, a "Transaction-id Out of Sequence" error message response MUST be sent to the requester, and the Request ignored until sequencing resumes. Message types not requiring response messages to be correlated to requests, such as those conveying events, SHOULD set the Transaction Id field to 0x0. In the event of an ANCP transport protocol failure, all pending ANCP messages destined to the disconnected recipient can be discarded until the transport is re-established following which the Transaction Identifier is re-initialized. The value of the Transaction Identifier in a Response message MUST be set to that of the respective Request message. This allows the Requester to correlate the Response to the original Request. The Champagne, et al. Expires January 3, 2009 [Page 4] Internet-Draft Multicast Control Extensions for ANCP July 2008 Transaction Identifier is not used in ANCP adjacency messages. Also, other ANCP applications not requiring it SHOULD set the Transaction Identifier to 0x0 in their messages. All TLVs within the ANCP message have to be 32 bit aligned, and when necessary padded with 0s to the 32 bit boundary. The padding is not reflected in the message length field. 4. ANCP Multicast Control Messages 4.1. Multicast Replication Control Request Message The Replication Control Request Message Type 0x90 (TBC) is sent by the ANCP Server (NAS) to the ANCP Client (AN) with a directive to either add (join) or delete (leave) one or more multicast flows on a target object identfied in the content of the message. An ANCP Client will use a Replication Control Response message when conveying the outcome of the directive, and this message type is covered in Section 5.1. The sender of a request message MUST set the Result field to either "AckAll" or "NAck", and SHOULD use "NAck" by default. Furthermore it SHOULD use the same Result field code for all Replication Control Messages sent, i.e. Result field changes SHOULD be avoided. The sender MUST populate the ANCP Transaction Identifier field with a distinct non-zero, linearly incrementing value for each Request per adjacency, as described in Section 3 . The ANCP Multicast Replication Control message payload contains the following TLVs: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Target-Type TLV | Length of Target-Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value = Target-Info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Command TLV | Length of Command Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value = Command Info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Target-Type: Champagne, et al. Expires January 3, 2009 [Page 5] Internet-Draft Multicast Control Extensions for ANCP July 2008 See Section 4.1.1. The Target-Ttype TLV (0xTBD) can only feature once in a replication Control Request Message, and it MUST be the first TLV in the message. Only one such TLV is allowed in this message type. Length of Target-Info: See Section 4.1.1 Target Info: See Section 4.1.1 Command TLV: The Command TLV (0xTBD) contains the multicast flow directive(s) for the target and any additional parameters passed via sub-TLVs. It MUST immediately follow the Target-type-TLV. See Section 4.1.2 Length of Command Info: Includes sub-TLVs. See Section 4.1.2 Command Info: Command information as defined below in section Section 4.1.2. The contents of the Command TLV for the Multicast Control Request Message are defined to be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code |R O M Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++| | Addr Family | Encoding Type | Multicast Flow Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+ Command Code: Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete All. Command Length: Champagne, et al. Expires January 3, 2009 [Page 6] Internet-Draft Multicast Control Extensions for ANCP July 2008 Length in bytes of each Command including multicast flow address, but excluding the Command Code header and flags. Flags: 8 bit General purpose Flag field. Currently the following flags are defined: R - Resource Admitted Flag. Set to 1 in an add command to indicate that the flow resources have been reserved by admission control, 0 otherwise. Not used in delete command. O - Flow Accounting. When set in add command indicates that byte accounting for the flow is to commence. M - When set indicates that multicast flow is SSM and the address-family-element set MUST specify the source and group addresses. When not set indicates that multicast flow is ASM and address- family-element MUST specify the group address, and the Source Address field is to be omitted. Note: Details regarding the interpretation of the Add and Delete command in view of SSM filter modes are to be addressed for future revisionins of this document. Address Family: The address family used The unicast source address/mask follows the format defined in [IANAAEA] Champagne, et al. Expires January 3, 2009 [Page 7] Internet-Draft Multicast Control Extensions for ANCP July 2008 Encoded-Unicast-address: Takes the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++ Encoding Type: The type of encoding used within a specific Address Family. The value `0' is reserved for this field, and represents the native encoding of the Address Family. The address as represented by the given Address Family and Encoding Type. Address: The address as represented by the given Address Family and Encoding Type. The padding will be done after both addresses so that it is 32-bit aligned. As an example for IPv4: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmdCode=0x01 |0 0 1 Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 0x1| Enc Type 0x0 | Src Address first 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address last 2 bytes | AddrFamily 0x1| Enc Type 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above example, no padding is required. A received Request Message containing an unrecognized Target-Type TLV MUST be communicated to the sender as an error in a Response Message indicating the "Unrecognised port Type - 0x04" error. The reception of a Request Message, or any ANCP message, that is found to have mandatory TLVs missing is to be addressed as part of a ANCP base protocol mechanism yet to be defined. Each Multicast Control Request Message may contain one or more command directives, each encapsulated by their own Command TLVs. The sender MUST use separate Command TLVs for each distinct multicast flow. When successive commands relate to a given target port and flow, the state of features controlled or affected by flags as well Champagne, et al. Expires January 3, 2009 [Page 8] Internet-Draft Multicast Control Extensions for ANCP July 2008 as by optional attributes received in the Request message, are to be interpreted as replacing any such previous state for that port and flow. As an example, successive Request messages containing add commands for a given port and flow, but differing in the accounting flag setting should be interpreted as affecting the state of the accounting feature. The recipient of a Request message is to run an implicit directive numbering across the multiple directives in the message. The numbering is to start from 0x01 for each directive in a given ANCP Request message, and be restarted for subsequent messages. The recipient MUST process the directives in the order of reception (i.e. The first command after the target type TLV info is to be executed first), and use the derived directive number in any response messages, besides the Transaction ID. The processing/execution of multiple directives contained in a single Multicast Control Request message MUST be interrupted at the first error, and the remaining commands in the Request message discarded. In such a case a multicast control response message MUST be sent indicating the command number that resulted in the error along with the error code. When the strict sequenced processing of the directives in a single Multicast Control Request message is not required the directives MUST be distributed across separate Request messages. Each command directive is equipped with an 8-bit Flags field that allows specification of Multicast ASM or SSM modes of operation, and an indication of other features or conditions attached to this command (e.g. To enable accounting for the flow, etc). Unassigned flags are reserved for future use, and could in the future be subject of the capability negotiation. When receiving a Multicast request Message containing an unrecognized Flag set (to 1), a recipient MUST interpret it as an error, and generate an Response message indicating the error. The multicast flow subject to the command is specified by means of one or two well known Address Family designators ([IANAAEA]), the IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When the M flag is set the two Address-Family tuples MUST be present in the strict order specifying the multicast flow source and group respectively. When the M flag is cleared only one Address-Family is allowed, specifying the multicast flow. For future extensibility, each command may also have additional TLVs appended following the command and multicast flow information (referred to as "TLVs" in the message format above). Unrecognized Champagne, et al. Expires January 3, 2009 [Page 9] Internet-Draft Multicast Control Extensions for ANCP July 2008 TLVs SHOULD be silently discarded. The figure below is an example of a Request message that would result in a swap from multicast SSM flows 10.1.1.1, 239.23.2.2, to 10.2.1.1, 239.55.3.2 on the target port identified by the "Access Loop Circuit ID": 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=90 | 0x02 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Target-type 0x1000 | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Command TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x02 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow : 239.23.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ | Type = Command-TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Source: 10.2.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily 01 | EncType 0x0 | Mcast Flow: 239.55.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. Target Type TLV The Target-type-TLV (TBD) is intended to be a general well known TLV allowing the representation of different types of objects. Its use is not restricted to any specific Message Type. Champagne, et al. Expires January 3, 2009 [Page 10] Internet-Draft Multicast Control Extensions for ANCP July 2008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target-type | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Target Info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Target-type TLV TLV (0xTBD) indicating the type of target being addressed. Numbers TBC. Tentative 0x1000 for single Access-Port. Target-TLV Length: Length in bytes of Target Info. Excludes TLV header Target Info: Target information as defined for each the given target type. The field can consist of sub-TLVs. In its simplest form, when targeting a single access line the Target- Type-TLV will be set to a value of (0xTBD), and carry in its payload one or more sub-TLVs identifying the target. The following example illustrates the message format for a single port identified by an Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a Port-UP message: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Target-type | Target-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2. Command TLV The Command TLV (TBD) is intended to be a general well known TLV allowing the encapsulation of one or more command directives in a TLV oriented message. The semantics of the command are allowed to be specified for each message type, ie different message types that choose to carry the Command TLV are expected to define the meaning of Champagne, et al. Expires January 3, 2009 [Page 11] Internet-Draft Multicast Control Extensions for ANCP July 2008 the content of the payload, which could be re-used from those already defined elsewhere if appropiate. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Command | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Command Info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional sub-TLV Type | Additional sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Additional sub-TLV data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command TLV: TLV (0xTBD) indicating the contents to be one or more command directives. Command TLV Length: Combined length in bytes of the data in Command Info and sub-TLV. Excludes the Command TLV header Commad-Info: Command information as defined for each message type. The field can consist of sub-TLVs. Additional sub-TLV: Additional sub-TLVs can be present in a command TLV. Any such sub-TLVs must directly follow each command. Additional sub-TLV Length: Number of actual bytes contained in the value portion of each additional sub-TLV 5. ANCP Multicast Response Messages Champagne, et al. Expires January 3, 2009 [Page 12] Internet-Draft Multicast Control Extensions for ANCP July 2008 5.1. Multicast Status Response Message The Multicast Status Response Message (Message Type 0x91 - TBC) is sent by the ANCP Client (AN) to the ANCP Server (NAS) in response to a Replication Control Request Message and its command directives. A Response message MUST use the same ANCP Transaction ID as that in the original Request Message. The Success or Failure status is reported in the Result field of the ANCP header as described in Section 3. A Response Message indicating Success SHOULD simply consist only of the base ANCP header with no body, however the message MAY contain one or more TLVs that are meant to communicate any relevant information to an application. The payload of a Response Message indicating Failure MUST contain an Status-Info TLV (0xTBD), as defined in Section 5.1.1, as its first TLV and SHOULD be followed by the Target-Type-TLV and Port-info. Other TLVs MAY be present. A Response message indicating Failure MUST be sent whenever a Multicast Control Request cannot be fulfilled or results in an execution error. The Cmnd Nmbr parameter in the Status-Info TLV contained by the Response Message is to indicate the number of the command in the Request that resulted in an error. 0x00 - Success 0x01 - Malformed message 0x02 - Command not supported 0x03 - Flag set but not supported 0x04 - Unrecognized Target Type 0x05 - Unsupported Address Family 0x06 - Malformed flow address 0x07 - No resources 0x08 - Unknown Port 0x09 - Target port down 0x0a - Configuration error (such as Port not enabled for multicast) 0x0b - Multicast flow does not exist 0x0c - Unsupported address encoding 0x0d - Additional info needed to execute command (payload MAY contain an indication of the expected info) 0x0e -Multicast flow count exceeded 0x0f - M Flag set, but no IP Source address provided 0x10 - Transaction-id out of sequence An example of a failure message for an invalid address, including the Target-Type TLV for a 4 byte "Access Loop Circuit ID", followed by TLV padding, is as follows: Champagne, et al. Expires January 3, 2009 [Page 13] Internet-Draft Multicast Control Extensions for ANCP July 2008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=91 | 0x4 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-info-TLV=TBD | Status-TLV-Length=14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | 0x01 | Target-type-TLV=0x100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-TLV-Length | 0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client-ID Length | Access Loop Circuit ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID cont... |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1. Status-Info TLV The Status-info-TLV is intended to be a general well known TLV used to convey the status code regarding commands and/or requests. The format of the Status-Info-TLV (TBD) is shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = Status-info | Status TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Cmnd Nmbr | Error Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (aligned to 4 bytes length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Status-info TLV: TLV (0xTBD) conveying the status or error response of a command Status TLV Length: Specifies the length in bytes of the Status Info TLV payload. Excludes the TLV header Champagne, et al. Expires January 3, 2009 [Page 14] Internet-Draft Multicast Control Extensions for ANCP July 2008 Result Code: Conveys the result code for the command or message, as defined by the application. Cmnd Nmbr: Contains the command number copied from the Request message. The value of 0 is used whenever the error is not specific to a command. Error Message Length: Contains the length of an optional error message or 0 if none. TLVs: This field is of indeterminate length, and contains zero or more of the TLVs associated with the Status-info-TLV. 6. Security Considerations Security of the ANCP protocol is discussed in [ANCPSEC] 7. IANA Considerations This proposal definies several new ANCP message types and well known mandatory TLVs. As such an application for an IANA assignment will need to be made. 8. Normative References [ANCPFW] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", draft-ietf-ancp-framework-06.txt, work in progress, October 2007. [ANCPPR] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and N. Voigt, "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-02.txt work in progress, March 2006. [ANCPSEC] Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security Champagne, et al. Expires January 3, 2009 [Page 15] Internet-Draft Multicast Control Extensions for ANCP July 2008 Threats and Security Requirements for the Acces Node Control Protocol (ANCP)", draft-ietf-ancp-security-threats-05.txt work in progress, March 2008. [IANAAEA] "http://www.iana.org/assignments/address-family-numbers", 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3292] Doria, A. and et all, "General Switch Management Protocol (GSMP) V3", June 2002. Authors' Addresses Philippe Champagne Cisco Systems 7025-4 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: Email: pchamp@cisco.com Wojciech Dec Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Phone: Email: wdec@cisco.com Sanjay Wadhwa Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Phone: phone Email: swadhwa@juniper.net Champagne, et al. Expires January 3, 2009 [Page 16] Internet-Draft Multicast Control Extensions for ANCP July 2008 Stefaan De Cnodder Alcatel-Lucent Copernicuslaan 50 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel-lucent.be Roberta Maglione Telecom Italia via Reiss Romoli 274 Torino Italy Phone: +390112285007 Email: roberta.maglione@telecomitalia.it Champagne, et al. Expires January 3, 2009 [Page 17] Internet-Draft Multicast Control Extensions for ANCP July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Champagne, et al. Expires January 3, 2009 [Page 18]