One document matched: draft-ancp-mc-extensions-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 14:29:12 |