1 / 20

ANCP Multicast Extensions draft-ancp-mc-extensions-00.txt

ANCP Multicast Extensions draft-ancp-mc-extensions-00.txt. Philippe Champagne, Stefaan De Cnodder, Roberta Maglione, Sanjay Wadhwa. Agenda. ANCP Header Multicast Replication Control Messages Open Issues Proposal. ANCP Header.

field
Download Presentation

ANCP Multicast Extensions draft-ancp-mc-extensions-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ANCP Multicast Extensionsdraft-ancp-mc-extensions-00.txt Philippe Champagne, Stefaan De Cnodder, Roberta Maglione, Sanjay Wadhwa IETF72 ANCP WG

  2. Agenda • ANCP Header • Multicast Replication Control Messages • Open Issues • Proposal IETF72 ANCP WG

  3. ANCP Header 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IETF72 ANCP WG

  4. Transaction ID Field • Used to distinguish between different Request messages and to associate a Response Message to the corresponding Request • It should be incremented linearly for each new message in the range (1, 2^24 - 1) • Transaction Identifier sequencing must be maintained independently for each ANCP adjacency and per message type • Message types not requiring response/request correlation (such as events) should set the Transaction Id field to 0x0 IETF72 ANCP WG

  5. Result field • Result field is derived from RFC3292 and renamed Result Code, it has the following codes: • Nack: Res = 0x1 - Result code indicating that no response is expected to the message other than in cases of failure • AckAll: Res = 0x2 - Result code indicating that a response to the message is requested in all cases. Not 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 Message • Failure: Res = 0x4 - Allowed to be set in Response Messages only to communicate failure of execution of one directives in a previous Request Message IETF72 ANCP WG

  6. Multicast Replication Control Messages • Multicast Replication Control Request: • Sent by the NAS to the AN with a directive to either join or leave one or more multicast flows • Message Type 0x90 • Multicast Status Response Message: • Sent by the AN to the NAS in response to a Multicast Replication Control Request • Message Type 0x91 IETF72 ANCP WG

  7. Message Flow +----------+ +-------+ +-----+ ANCP +-----+ |Subscriber| | Home | | AN |<-------------->| NAS | +----------+ |Gateway| +-----+ +-----+ | +-------+ | | | | | | | | | Replication-Crtl( | | | | Target,add Flow1) | | | |<--------------------| | Mcast Flow 1 | | |<==========================+ | | | |Replication-Response | | | | (status) | | | |-------------------->| | | | | | | | Replication-Crtl( | | | | Target,delete Flow1)| | | |<--------------------| | | | | | <Stop Replication of x | | Mcast Flow 1> |Replication-Response | | | | (status) | | | |-------------------->| IETF72 ANCP WG

  8. Replication Control Request • Transaction Identifier: • The sender must populate the ANCP Transaction ID field with a distinct non-zero linearly incrementing value for each Request per adjacency • Result Field: • The sender must set the Result to either "AckAll" or "NAck“ ("NAck" is the default) • Message Payload: • Target Type TLV • Command TLV IETF72 ANCP WG

  9. Replication Control Request 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IETF72 ANCP WG

  10. Target TLV • The Target-type TLV (0xTBD) is a generic wrapper TLV for a class of objects (single Access-Line, group-of-access-lines, etc.) Future definition of new targets requires the asssignment of new target type numbers This TLV is intended to be re-usable across the messages • Example of Target-type TLV for a single Access-Line 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IETF72 ANCP WG

  11. Command TLV • The Command TLV (0xTBD) is a generic wrapper TLVand contains one or more multicast flow command directive(s) for a given target. This TLV is intended to be re-usable across the messages 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+ IETF72 ANCP WG

  12. Command TLV • Command directives: • 0x01 - Add • 0x02 - Delete • 0x03 - Delete All • Flags: 8 bit General purpose Flag field • R: Resource Admitted Flag (only used for “Add” set to 1 to indicate resources reserved) • O: Flow Accounting if set in “Add” indicates that byte accounting for the flow is to commence • M: set to 1 if multicast flow is SSM, 0 for ASM • Address Family IETF72 ANCP WG

  13. Command TLV • A single Multicast Replication Control Request Message may feature several commands, which will be interpreted sequentially. Each command is encapsulated in the Command TLV • The sender MUST use separate Command TLVs for each distinct multicast flow • The recipient of a Request message is to run an implicit directive numbering across the multiple directives in the message • The recipient MUST process the directives in the order of reception and use the derived directive number in any response messages, besides the Transaction ID IETF72 ANCP WG

  14. Command TLV • 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 case of failure of one directive 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 Replication Control Request message is not required the directives must be distributed across separate request messages IETF72 ANCP WG

  15. Replication Control Response • Transaction Identifier: • A Response message must use the same ANCP Transaction ID as that in the original Request Message • Result Field: • Is used to report Success or Failure status • Message Payload: • A Replication Response Message indicating Success should consist only of the base ANCP header with no body, however it may contain one or more TLVs • A Replication Response Message indicating Failure must contain an Status-Info TLV and should be followed by the Target-Type TLV IETF72 ANCP WG

  16. Status-Info TLV • The Status-Info TLV is a generic wrapper TLV that contains the status code regarding commands and/or requests and it may carry additional sub-TLVs This TLV is intended to be re-usable across the messages 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IETF72 ANCP WG

  17. Status-Info TLV • Command Number: • indicates the number of the command in the Request Message that resulted in an error • Error Message codes: 0x00 – Success 0x01 - Malformed message 0x02 - Command not supported 0x03 - Flag set 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 0x0b - Multicast flow does not exist 0x0c - Unsupported address encoding 0x0d - Additional info needed to execute command 0x0e -Multicast flow count exceeded 0x0f - M Flag set, but no IP Source address provided 0x10 - Transaction-id out of sequence IETF72 ANCP WG

  18. Open Issues • Determining the behaviour for (S,G) flows in case of SSM • Do we need additional command directives? • Modify? • Lack of base protocol functionality for dealing with protocol errors (eg. missing TLVs) • Which new capabilities have to be defined? • Related ANCP MIB • … • Others? IETF72 ANCP WG

  19. Proposal • To have the contents of this draft accepted by the WG and incorporated into section 4.4 of ANCP Protocol ID IETF72 ANCP WG

  20. Questions/Discussion Thanks! IETF72 ANCP WG

More Related