[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ANCP] Proposal for replacement of "Multicast Status" message, Part 1
I had an action out of last meeting to propose a base-level replacement for the
Multicast Status message.
Further to this topic, Fortune Huang pointed out that the use of Multicast
Status as an error response to the Delegated Bandwidth Query request is an
unnecessary complication. The point seems to be valid. As a general principle
for our specification work, I propose the following:
If a specific response type is defined for a particular message, the correct
way to report a failure is to send that response with the Result field set to
Failure and the Code field set to an appropriate value.
In looking at the new generic response message, I also wondered why the GSMPv3
error mechanism is duplicated in the Status-Info TLV. The Result Code field in
Status-Info is really the Code field in the header that has to be set to the
right value when the header Result field is set to Failure. It would seem to
make more sense to use the GSMPv3 mechanism, and use the Status-Info TLV just to
add information that GSMPv3 lacks. In particular, to aid in correlation,
Status-Info should contain the sent Message Type value. Given that that Command
TLVs will be present only in a limited set of message types, and "Cmnd Nmbr" is
not one of the fields defined within the Command TLV, I would also remove "Cmnd
Nmbr" from Status-Info. It can always be specified as part of the failure
response to a particular message type.
With these preliminary considerations, here are my text proposals for moving the
generic response message (AKA Multicast Status) to base. These proposals apply
to the base document (draft-ietf-ancp-protocol-06) only. The changes to the
multicast extensions document (draft-ietf-ancp-mc-extensions-00.txt) will be
described in another message.
1. Modifications to base protocol section 5, description of Code field
======================================================================
Add the following text to the description of the Code field:
<begin>
ANCP implementations MAY use any of the Code values specified in the IANA
registry "Global Switch Management Protocol version 3 (GSMPv3) Failure Response
Message Name Space" if they appear applicable. In particular, the values:
2 Invalid request message (i.e., a properly formed message which
violates the protocol through its timing or direction of
transmission).
4 One or more of the specified ports does not exist.
6 One or more of the specified ports is down.
7 Invalid Partition ID.
19 Out of resources (e.g. memory exhausted, etc.).
30 The limit on the maximum number of point-to-
multipoint connections that the switch can support
has been reached.
31 The limit on the maximum number of branches that
the specified point-to-multipoint connection can
support has been reached.
may unfortunately apply to ANCP usage, including the case where "port" is
interpreted to mean Target as defined in section 5.4.5.1. Instead of the value:
3 The specified request is not implemented on this switch.
specified by RFC 3292, this specification defines a new value:
81 Request message type not implemented.
This value MAY be sent in a failure response from either the AN or the NAS. This
specification also defines the additional values:
82 Transaction identifier out of sequence.
83 Malformed message.
ANCP extensions defining new code values SHOULD use the range 0x0100 through
0x01ff for this purpose.
<end>
2. Modifications to base protocol section 5.4.5.1.3 Status-Info TLV
====================================================================
(a) Remove the Result Code and mark the field as "Reserved". Indicate that it
MUST be set to zeroes by the sender and ignored by the receiver.
(b) Change the term "command number" to "message type" and modify the field name
accordingly from "Cmnd Nmbr" to "Msg Type".
3. New base protocol section 5.4.5.2 General Response Message
=============================================================
Here is the proposed text.
<begin>
5.4.5.2 Generic Response Message
This section defines the Generic Response message. The Generic Response message
may be specified as the appropriate response to a message defined in an
extension to ANCP, instead of a more specific response message. As a general
guideline, specification of the Generic Response message as a response is
appropriate where no data needs to be returned to the peer other than a result
(success or failure), plus, in the case of a failure, a code indicating the
reason for failure and a limited amount of diagnostic data. Depending on the
particular use case, the Generic Response message MAY be sent by either the NAS
or the AN.
The AN or NAS MAY send a Generic Response message indicating a failure condition
independently of a specific request before closing the adjacency as a
consequence of that failure condition. In this case, the sender MUST set the
Transaction Identifier field in the header and the Message Type field within the
Status-info TLV to zeroes. The receiver MAY record the information contained in
the Status-info TLV for management use.
The format of the Generic Response message is shown in Figure 17.
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 |Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x12 | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 17 - Structure of the Generic Response Message
Message Type
The message type value for the Generic Response message is 0x91.
Result
The value of the Result field for the Generic Response message MUST be
either Success (0x03) or Failure (0x04).
Code
The Code field MUST have value zero if Result is set to Success (0x03).
It MUST have an appropriate non-zero value if Result is set to Failure
(0x04). As discussed in section 5, extensions to ANCP MAY define new Code
values for use in failure responses for specific request message types.
Partition ID
As specified in section 5.
Transaction Identifier
The Transaction Identifier MUST be copied from the request to which the
Generic Response message is responding.
I, Sub-message Number, Length
As specified in section 5.
Status-info TLV
MAY be present in a success response, to provide a warning as defined for
a specific request message type. MUST be present in a failure response.
The Message Type field value is copied from the header of the request
message. The Error Message field contains human-readable diagnostic text.
The description of the response for a particular request message type MAY
specify further sub-TLVs to be included in Status-info, either generally
or for specific failure Code values.
<end>
4. Modifications to base protocol IANA section
==============================================
(a) Add the following text preceding the paragraph beginning:
"This document reserves the range 0x500 to 0x5ff of GSMPv3 Failure
Response Message Name Space registry ..."
<begin>
This document adds the following values to the GSMPv3 Failure Response Message
Name Space registry:
Value Failure Response Message Name Reference
------- ---------------------------------------------------------- ---------
81 Request message type not implemented. [This RFC]
82 Transaction identifier out of sequence. [This RFC]
83 Malformed message. [This RFC]
This document reserves the values 0x100 to 0x1ff (256 to 511) within the GSMPv3
Failure Response Message Name Space registry for use by extensions to the Access
Node Control Protocol (ANCP).
<end>
(b) Delete the proposed ANCP Status-Info Result Code registry.
Tom Taylor