Internet Draft Internet-Draft Joachim Buerkle 9. November 1999 Bosch Telecom Expiration Date: 8. May 2000 Extended move branch concept for GSMP <draft-buerkle-gsmp-move-branch-message-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Some multicast applications, such as Video distribution, need an efficient support for moving between multicast groups. This draft shows that the support of such application results in a extended move branch concept of GSMP to be able to move the Output branch of a connection not only to another port but also between connections with the same QoS. Buerkle 1999 Expiration Date: 8. May 2000 [Page 1] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 Overview Some GSMP applications, which are using zapping protocols to switch between different content streams (multicast groups), need the possibility to switch the output branch of connection to another connection with the same QoS. Since zapping between content streams is a highly time critical action this draft proposes to generalized respectively extended move branch concept of GSMP. 1. Current Situation The Move Branch message of [1] is used to move a branch of an Existing connection from its current output port label to a new output port label in a single atomic transaction. As defined in [1] the Move Branch message is a connection management message used to move a single output branch of connection from its current Output Port and Output Label, to a new Output Port and Output Label on the same connection. None of the connection's other Output Branches are modified. When the operation is complete the original Output Label on the original Output Port will be deleted from the Connection. Furthermore [1] defines as an ATM specific procedure the ATM VPC Move Branch. The ATM VPC Move Branch message is a connection management message used to move a single Output Branch of a virtual path connection from its current Output Port and Output VPI, to a new Output Port and Output VPI on the same virtual channel connection. None of the other Output Branches are modified. When the operation is complete the original Output VPI on the original Output Port will be deleted from the connection. 2. New Requirement The new requirement of GSMP multicast applications, such as Video distribution, is that GSMP provides a single atomic transaction to move an Output Branch of a connection (e.g. a VCC) to another existing connection (e.g. a VCC). Both connection must have the same specified QoS. Buerkle 1999 Expiration Date: 8. May 2000 [Page 2] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 3. Possible Concepts It is possible to consider a the move of Output branches between existing connections (in case of a Port-Type=ATM VCCs) as a variant of the GSMP move branch message, or as a distinct object in its own right. The former would involve an extended definition of the move branch message while the latter would involve a new additional connection management message. Which of these variants will be chosen is up to the GSMP WG consensus. 3.1. Changes to GSMP with the first variant The first variant means that there is no change of the message Format but the Port and Label fields of the message are used in Dependence of the message type. The message will then defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unchanged Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|E| Unchanged Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** ~x x x|E| Unchanged Extended Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | To be changed Old Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x|E| To be changed Old Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** ~x x x|E| To be changed Extended Old Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | To be changed New Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|x|E| To be changed New Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** ~x x x|E| To be changed Extended New Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Buerkle 1999 Expiration Date: 8. May 2000 [Page 3] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 ** Note: There can be zero or more 32 bit words containing Extended Labels (like those marked **) following an Input or Output Label field. A 32 bit word containing an Extended Label follows the previous label field if and only if the E Flag immediately preceding the previous label is set. The E, QMS and Service Selector fields are as defined in the Add Branch message of [1]. The Port and Label Fields are then used for the different message Types as defined as follows: In the cases of GSMPs message types: - #22 - #27 the port and label fields must be used for the existing as defined in [1]. This means: - Unchanged Port = Input Port - Unchanged Label = Input Label - Unchanged Extended Label = Extended Input Label - To be changed Old Port = Output Port - To be changed Old Label = Output Label - To be changed Extended Old Label = Extended Output Label - To be changed New Port = Output Port - To be changed New Label = Output Label - To be changed Extended New Label = Extended Output Label In this case where the move branch message is used to move an Output branch between existing connections (in case of a Port-Type=ATM VCCs) a new message type must be defined and the port and label fields must be used as defined as follows. This means: - Unchanged Port = Output Port - Unchanged Label = Output Label - Unchanged Extended Label = Extended Output Label - To be changed Old Port = Input Port - To be changed Old Label = Input Label - To be changed Extended Old Label = Extended Input Label - To be changed New Port = Input Port - To be changed New Label = Input Label - To be changed Extended New Label = Extended Input Label Buerkle 1999 Expiration Date: 8. May 2000 [Page 4] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 3.2. Changes to GSMP with the second variant The second variant means that there will be no changes for the definition of the existing move branch message of [1] and that there will be an additional request message which used to move Output Branches between existing VCCs. This additional request message is based on the frame format of the current move branch message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|E| Output Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|E| Old Input Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|x|E| New Input Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** ~x x x|E| To be changed Extended New Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version, Message Type, Result, Code, Partition ID, Transaction Identifier, Port, QMS and Service Selector fields are as defined in [1]. If in this case the message is used just for ports with attribute PortType=ATM the port's labels must be interpreted as ATM Labels as defined in [1]: Buerkle 1999 Expiration Date: 8. May 2000 [Page 5] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 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 + - - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | VPI | VCI | + - - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since ATM ports do not support Extension Labels so the VPI and VCI values always occupy the 28 bits following the flags in a connection management message. The Message Type for this new message is to be defined by the GSMP WG for the general and the ATM specific case. 4. Behavior in case of the new move branch message No matter which variant will be chosen by the GSMP WG the behavior of the new message will be defines as follows. If the connection specified by the Old Input Port and Old Input Label (e.g. VPI/VCI) and the branch specified by the New Input Port and New Input Label (e.g. VPI/VCI) fields already exists, and the Output Branch specified by the Output Port and Output Label (e.g. VPI/VCI) fields exists as a branch on the connection specified by the Old Input Port and Old Input Label (VPI/VCI), the Output Branch is added to the connection respectively branch specified by the New Input Port and the New Input Label. When the operation is complete the original Output Label (e.g. VPI/VCI) on the original Output Port will be deleted from the connection (e.g. VCC). If the Result field of the request message is "AckAll" a success response message must be sent upon successful completion of the operation. The success response message must not be sent until the Move Branch operation has been completed. This means that with this message a single output branch of Connection (e.g. VCC) is moved from its current Input Port and Input Label (e.g. VPI/VCI), to a New Input Port and Input Label (e.g. VPI/VCI) on another connection (e.g. VCC) which has the same QoS specified in the Service Selection field. None of the connection's (e.g. VCCs) other Output Branches are modified. If the connection specified by the Old Input Port and Old Input Label fields does not exist, a failure response must be returned with the Code field indicating, "The connection specified by the Old Input Port does not exist." Buerkle 1999 Expiration Date: 8. May 2000 [Page 6] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 If the connection specified by the Old Input Port and Old Input Label fields already exists, but the Output Branch specified by the Output Port and Output Label fields does not exist as a branch on that connection, a failure response must be returned with the Code field indicating, "The specified Output branch does not exist." If the connection specified by the Old Input Port, Old Input Label, Output Port and Output Label fields does exist, but the connection specified by the New Input Port and New Input Label does not exists a failure response must be returned with the Code field indicating, "The specified New Input branch does not exist." 4.1. ATM specific Part (Port-Type=ATM) As it is current practice in [1] for ATM, there shall be a separate message type for the ATM specific case of this operation. In the ATM case this operation makes only sense for virtual channel Connections, so the movement of VPC shall not be supported. A failure response message must be returned in the VPC case indicating , "This operation is not supported for VPCs." The Move Branch message is in this ATM case a connection management message used to move a single output branch of a virtual channel connection from its current input port and current Input VPI/VCI, to a New Input Port and New Input VPI/VCI on a different virtual channel connection. None of the other Output Branches are modified. When the operation is complete the original Output VPI/VCI on the original connection specified by the Old Input Port and Old Input VPI/VCI will be deleted from the connection. If the virtual channel connection specified by the Old Input Port and Old Input VPI/VCI field does not exist, a failure response must be returned with the Code field indicating, "The virtual channel connection specified by the Old Input Port does not exist." If the virtual channel connection specified by the Old Input Port and Old Input VPI/VCI field already exists, but the output branch specified by the Output Port and Output VPI/VCI field does not exist as a branch on that connection, a failure response must be returned with the Code field indicating, "The specified Output branch does not exist." Buerkle 1999 Expiration Date: 8. May 2000 [Page 7] INTERNET-DRAFT Extended move branch concept 9. Nov. 1999 If the virtual channel connection specified by the New Input Port and New Input Label fields does not exist, a failure response must be returned with the Code field indicating, "The virtual channel connection specified by the New Input Port does not exist." If the Output Branch specified by the New Input Port, New Input VPI, and New Input VCI fields for a virtual channel connection; is already in use by any connection other than that specified by the Output Port and Output Label fields then the resulting new input branch will have multiple Output Branches. If multiple point-to- point connections share the same Output Branch the result will be a multipoint-to-point connection. If multiple point-to-multipoint trees share the same Output Branches the result will be a multipoint-to-multipoint connection. 5. Modifications If the GSMP WG decides to go along with another header format, like it is proposed in [2], the proposal of this draft can be easily mapped also to this new message format. 6. References [1] Tom Worster, et. al., "General Switch Management Protocol", <draft-ietf-gsmp-02.txt>, Oct. 1999. [2] Matt Peters, Balaji Srinivasan, Jaroslaw Sydir, "GSMP enhancements" <draft-sydir-cplane-gsmp-enhancements-00.txt>, Oct. 1999. Authors' Contact Joachim Buerkle @ Bosch Telecom GmbH Phone: +49 7191 13 4602 Gerberstrasse 33 Telefax: +49 7191 13 64602 71522 Backnang Email: joachim.buerkle@de.bosch.com (Germany) Germany jbuerkle@rtp-bosch.com (USA) Buerkle 1999 Expiration Date: 8. May 2000 [Page 8]