Subject: [ANCP] Proposal for replacement of "Multicast Status" message, Part 1

From: Tom Taylor <[email-masked]>
Date: Tue, 25 Aug 2009 20:58:35 -0400

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