ForCES Working Group Weiming Wang Internet-Draft Ligang Dong Expires: Jan., 2006 Zhejiang Gongshang Univ. July 2005 ForCES Protocol Transport Mapping Layer (TML) Over IP Networks draft-wang-forces-iptml-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. Copyright Notice Copyright (C) The Internet Society (2005). Conventions used in this document 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]. Abstract This document defines ForCES Transport Mapping Layer (TML) over IP networks, the framework and the specifications to meet the ForCES TML requirements. Internet Draft ForCES TML over IP July 2005 Table of Contents 1. Introduction....................................................2 2. Definitions.....................................................2 3. ForCES TML Overview.............................................3 3.1. TML in ForCES Framework....................................3 3.2. TML Requirements...........................................6 3.3. PL-TML Service Primitives..................................7 4. IP TML Framework................................................7 4.1. Connection Manager Component (CMC).........................9 4.2. Arbiter Component (AC)....................................10 5. IP TML to meet TML Requirements................................11 5.1. Reliability...............................................11 5.2. Security..................................................12 5.3. Congestion Control and Protection against DoS Attacks.....12 5.4. High Availability.........................................12 5.5. Multicast.................................................12 5.6. Prioritization............................................14 5.7. Encapsulation.............................................14 6. IP TML Messages................................................15 7. Security Considerations........................................16 8. IANA Considerations............................................16 9. References.....................................................16 10. Author's Address..............................................16 1. Introduction The Forwarding and Control Element Separation (ForCES), the requirements have been defined in RFC3654, and the framework in RFC3746. The ForCES protocol, which standardizes the interface between Control Element (CE) and Forwarding Element (FE), is being defined in [ForCES-PL] by IETF. Variant transport media (like IP, ATM, Ethernet, etc) may be applied to ForCES protocol for the interconnection between CE and FE. To make the ForCES protocol specification independent of these variant transport means, a Transport Mapping Layer (TML) is induced in the ForCES protocol framework [RFC3746]. It is expected that different TML specifications be individually defined in IETF. This document defines the ForCES TML over IP networks, its framework and its specifications to meet the TML requirements. 2. Definitions Many definitions related to ForCES can be found in RFC3654, RFC3746 and the ForCES protocol [ForCES-PL], like: W. M. Wang Expires Jan., 2006 [Page 2] Internet Draft ForCES TML over IP July 2005 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, as well as the ForCES protocol architecture itself. ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc), and how to achieve and implement reliability, multicast, ordering, etc. This document defines the following notions: ForCES TML over IP networks -- TML for ForCES protocol that are applied to CE-FE interconnect networks, which run IP protocol at the Network Layer. ForCES IP TML -- Specifically means ForCES TML over IP networks in this document. Connection Manager Component (CMC) -- a component in IP TML that is responsible for all IP TML level connection management. Arbiter Component (AC) -- a component in IP TML that is responsible for putting PL messages into IP TML level connections. 3. ForCES TML Overview 3.1. TML in ForCES Framework The ForCES protocol[ForCES-PL] has defined the relationship between ForCE PL and TML in the protocol framework, as shown in Figure 1. CE and FE form a peer-to-peer structure in the framework, where CE PL peers to FE PL and CE TML peers to FE TML. A TML always lies below a PL in the same ForCES NE and provides services to the PL. Interface between PL and TML is standardized by means of a set of service primitives[]. +----------------------------------------------- | CE PL layer | +----------------------------------------------- | CE TML layer | +----------------------------------------------- ^ | ForCES | PL Messages | W. M. Wang Expires Jan., 2006 [Page 3] Internet Draft ForCES TML over IP July 2005 over TML | | | | | | | | v +----------------------------------------------- | FE TML layer | +----------------------------------------------- | FE PL layer | +----------------------------------------------- Figure 1. The TML in the ForCES Protocol Framework ForCES TML can also be observed from ForCES framework[] point of view. It is then observed with two phases, the ForCES pre-association phase and the ForCES post-association phase[RFC3746]. During ForCES pre-association phase, a CE/FE TML should usually be firstly managed by CE Manager(CEM)/FE Manager(FEM), as shown in Figure 2, so as to be pre-configured with some initialization parameters, like parameters of TML connections. +-----------+ +-----------+ | CEM | | FEM | +-----------+ +-----------+ ^ ^ +-----------|------------+ +-----------|------------+ |CE | | |FE | | | ... Y | | ... Y | | +-----------+ | | +-----------+ | | | TML | | | | TML | | | +-----------+ | | +-----------+ | | ^ | | ^ | +-----------|------------+ +-----------|------------+ +---------------------------------+ Figure 2. TML during ForCES pre-association phase Note that although Figure 2 shows CEM/FEM being entities outside CE/FE, it is also possible CEM/FEM are physically embedded in CE/FE. During ForCES post-association phase, ForCES PL is activated. TML is then associated to the local PL. From ForCES model point of view, to associate a CE/FE TML to the CE/FE PL is actually to associate the CE/FE TML to the CE/FE protocol LFB in the CE/FE. Note that at the same time, TMLs will have to still be associated to CEM/FEM. (This actually infers that CEM/FEM will still be active during the post- W. M. Wang Expires Jan., 2006 [Page 4] Internet Draft ForCES TML over IP July 2005 association phase). Figure 3 shows the diagram for TML during post- association phase. +-----------+ +-----------+ | CEM | | FEM | +-----------+ +-----------+ ^ ^ | | +------------------------+ | | +------------------------+ |CE | | | |FE | | ... ... | | | | ... ... | | | | | | | | +---------------+ | | | | +---------------+ | | |CE LFB | | | | | |FE Protocol LFB| | | | ... | | | | | | ... | | | | +-----------+ | | | | | | +-----------+ | | | | | LFB Core | | | | | | | | LFB Core | | | | | +-----------+ | | | | | | +-----------+ | | | | ^ | | | | | | | ^ | | | | |Service | | | | | | | |Service | | | | | Primitives| Y | | | | | Primitives| Y | | | | +-----------+ | | | | | | +-----------+ | | | | | TML |<------ + +------>| TML | | | | | +-----------+ | | | | +-----------+ | | | | ^ | | | | ^ | | | +-------|-------+ | | +-------|-------+ | +-----------|------------+ +-----------|------------+ | | +---------------------------------+ Figure 3. TML during ForCES pre-association phase (Editor: ForCES CE LFB is still an entity that is under discussion in ForCES protocol specification. To say CE TML is associated to CE LFB is actually to say CE TML is associated to an object that manages the ForCES protocol PL layer at the CE side, therefore, whether it is called a CE LFB is not the key point here.) Figure 3 also indicates that: 1. TML properties (attributes, capabilities, events, etc) appearing at the PL level are actually part of the properties of CE/FE Protocol LFB. 2. PL-TML Service Primitives are used by cores of CE/FE Protocol LFB to access the TML properties as well as to send/receive PL messages from TML. From Figure 3, we also see that, TML receives management from both PL layer and CEM/FEM during the post-association phase. It is important to recognize the difference of the two types of management. CEM/FEM management for TML at post-association phase is a consistent W. M. Wang Expires Jan., 2006 [Page 5] Internet Draft ForCES TML over IP July 2005 management from pre-association phase, which is mainly for TML connection management, while PL level management for TML is for the management that is independent of actual TML medias and only based on the uniformly defined service primitives that are applicable to all kinds of TMLs. 3.2. TML Requirements The ForCES protocol[ForCES-PL] has defined the general requirements to all types of ForCES TMLs, as below: 1. Reliability As defined by RFC 3654, section 6 #6. 2. Security TML provides security services to the ForCES PL. TML layer should support the following security services and describe how they are achieved. * Endpoint authentication of FE and CE. * Message Authentication * Confidentiality service 3. Congestion Control The congestion control scheme used needs to be defined. Additionally, the circumstances under which notification is sent to the PL to notify it of congestion must be defined. 4. Uni/multi/broadcast addressing/delivery if any If there is any mapping between PL and TML level Uni/Multi/Broadcast addressing it needs to be defined. 5. Timeliness 6. HA decisions It is expected that availability of transport links is the TML's responsibility. However, on config basis, the PL layer may wish to participate in link failover schemes and therefore the TML must support this capability. 7. Encapsulations used. Different types of TMLs will encapsulate the PL messages on different types of headers. The TML needs to specify the encapsulation used. 8. Prioritization It is expected that the TML will be able to handle up to 8 priority levels needed by the PL layer and will provide preferential treatment. TML needs to define how this is achieved. 9. Protection against DoS attacks As described in the Requirements RFC 3654, section 6 W. M. Wang Expires Jan., 2006 [Page 6] Internet Draft ForCES TML over IP July 2005 3.3. PL-TML Service Primitives PL-TML service primitives should be uniformly defined by IETF [ForCES-SP], so that CE can uniformly define PL operations for all kinds of TMLs. 4. IP TML Framework We define the architectural framework of ForCES TML over IP networks(IP TML) as in Figure 4. Note that this framework applies to both CE TML and FE TML over IP networks. ------------------------------------------------------------------- PL Layer TMLconfig TMLevent TMLsend TMLrecv TMLconfig TMLopen Service TMLclose ^ | ^ | --- Primitives ----|---------|----------------|---------|--------|-- | | Control | Redirect| | IP TML Layer | | Messages | Messages| | | | / \ | | | | / \ | | | | V V | | | | | | | | | | | | |--| |--| | | | | |--| |--| | | | | +--+ +--+ | | | | | | | | | | V V | | | | +-----------------------------+ | | +----->+<-| Arbiter Component (AC) |<-+ | | ------->+-----------------------------+ | | | / \ V | V . . . . . . . .| |. . . . . . . . . +----------+ . | | . Ctrl. from |Connection| . | |TCP-UDP pair . CEM/FEM ------>|Manager |-->. | |Connection(s) . |Component |<--. | | . |(CMC) | . . . . . . . .| |. . . . . . . . . +----------+ | | ------ Sockets ---------------- | | TCP/UDP Layer | | ------------------------------- | | IP Layer | | and Below | | -------------------------------------------------------------------- \ / Network Interface(s) W. M. Wang Expires Jan., 2006 [Page 7] Internet Draft ForCES TML over IP July 2005 Figure 4. Framework of IP TML IP TML as showed in Figure 4 uses a so-called ”TCP-UDP pair connection” for interconnection between CE TMLs and FE TMLs. A TCP- UDP pair connection contains a TCP connection and a UDP connection, which MUST have the same source and destination IP addresses and port numbers. We define that IP TML connections should always be established in the form of TCP-UDP pair connection format, i.e., whenever a TCP connection is established, a UDP connection with the same source and destination addresses should also be available for the IP TML. Note that, because UDP is generically capable of multicast, a UDP in a TCP-UDP pair is still capable of multicast when it gets support from multicast protocols. The TCP-UDP pair connections are managed by a component so- called ”Connection Manager Component (CMC)”. The CMC is responsible to all TML connections for the establishment and release, security of the connections, HA management (at only the TML connection level). Usually CMC fulfills these tasks by receiving configuration information from CE/FE Managers as described in Figure 2 and Figure 3. CMC also receives configuration information from local PL layer by the PL running TMLConfigure service primitives. Section 4.1 describes in details the CMC component. This IP TML framework also defines that interfaces between PL and TML should completely comply with the uniformly defined PL-TML service primitives [ForCES-SP]. When PL messages are generated by PL layer, they are sent to TML layer by the TMLsend service primitives. IP TML receives the PL messages and put the messages into two separate message queues according to the types of the PL messages. PL messages with ’Redirect Message’ type are put in a redirect message queue, while all other messages that are called control messages are put in a control message queue. PL messages are then put into TML level connections via a component called “Arbiter Component (AC)”. The AC decides when and which TML connections PL messages already in the two PL message queues should be injected into. Usually IP TML uses socket interfaces to put the messages in the IP TML connections. The AC also receives PL messages from peer TML via the TML connections, and makes them ready for local PL layer to fetch by the PL using TMLReceive service primitives. W. M. Wang Expires Jan., 2006 [Page 8] Internet Draft ForCES TML over IP July 2005 The AC may also generate TML events according to the TML connection state and notifies local PL layer of the events. The TML events should comply with the TML event specifications defined in the PL-TML service primitives[ForCES-SP]. The AC has to receive configuration information from PL layer via TMLconfigure service primitive. The AC will also share information about TML connections with CMC. The TML Connection Table in the CMC can also be accessed by AC. AC will then use the table to arbitrate PL messages and to put them in TML connections. PL messages are encapsulated to TCP/UDP packets in AC before they are put in IP TML connections or decapsulated in AC when received and before being output to PL. Section 4.2 describes in details the AC component. 4.1.Connection Manager Component (CMC) The Connection Manager Component (CMC) receives configuration information from CE manager (if it is a CE TML) or FE manager (if a FE TML), as well as from local PL layer. There is only one kind of TML connections defined in this IP TML: TCP-UDP pair connection(s). A recommendation for the assignment of the TCP-UDP pairs is as below: 1. A base TCP-UDP pair connection between every CE and every FE MUST be applied. 2. Multiple TCP-UDP pair connections between one same CE and one same FE MAY be applied for the sake of requirements like prioritization. 3. PL control messages always use TCP in the TCP-UDP pair connection(s) for transportaion. 4. PL redirect messages always use UDP in the TCP-UDP pair connection(s) for transportation. The following steps are adopted to establish a TCP-UDP pair connection between a CE and a FE: 1. CMC in a CE acts as a server and waiting for a TCP connection from FEs 2. CMC in a FE acts as a client, and it should have got information from the FE manager for connecting to peer CE TML, which usually include the IP address and the port number for the CE TML. 3. CMC in the FE makes a TCP connection to the CE TML. 4. A UDP connection with the same source and destination addresses should be simultaneously and implicitly established. W. M. Wang Expires Jan., 2006 [Page 9] Internet Draft ForCES TML over IP July 2005 CMC maintains a table called ”TML Connection Table”. This table contains information about all TCP-UDP pair connections that have been established. For every TCP-UDP pair connection, the table usually contains the following information: . Connection destination CE/FE ID . Connection destination IP address and port number PL Message type(s) the connection applies for . PL Message priority(s) the connection applies for (Editor: How the table is established in CMC is still under consideration.) The TML connections establishment process usually happens when TML receives TMLopen service primitives from local PL. When a new FE is up and is going to associate itself to a CE, the FE PL usually needs to open the TML first, then to send a FE Association Message to join. All active TML connections will be closed and shutdown if a TMLclose service primitive is received from local PL by a TML. When a FE is going to leave an CE, it will have to tear itself down first by sending a FE teardown message to CE, then for the PL to send a TMLclose primitive to local TML to close all TML connections. TML connections still can be modified or released, or some new connections can be added after TMLopen service primitive has been executed. All newly modified connection information will immediately trigger CMC to change the connection state. A TML event regarding such connections change will be triggered and notified to PL if PL has subscribed for such TML event. CMC generates TML events and notify local PL of the events by executing corresponding callback functions, which is logged during PL subscription of these events. The TML events generated by CMC are: .TML failure event. This event will happen when the minimum required TML connections (as described above) are unavailable. (More TBD) 4.2.Arbiter Component (AC) Arbiter Component (AC) should fulfill the following tasks: 1. To decide when and at what a pace to inject PL messages into TML connections W. M. Wang Expires Jan., 2006 [Page 10] Internet Draft ForCES TML over IP July 2005 By AC fulfilling this task, it is expected the IP TML will meet the TML requirements for prioritization, congestion control, and protection against DoS attacks from redirect data. 2. To decide which connection(s) a PL message to be injected into. AC does this work by use of the ”TML Connection Table” generated by CMC and shared by the AC as described above. AC will use the ”Destination ID”, ”Message type” and ”Message priority”, which are associated with every message received from PL, to match the table to find out the corresponding IP TML connection(s). 3. To encapsulate PL messages to packets of TML connections or to decapsulate PL messages from packets of TML connections. 4. To receive PL messages from TML connections and send them to PL by use of TML service primitives On receiving packets coming from peer TML, the IP TML just de- encapsulate them to get PL messages, then to put the messages in a receive queue waiting for PL to use service primitive to fetch. 5. To generate TML events and to notify local PL of the events by executing corresponding callback functions if the events have been subscribed by the PL. The TML events generated by AC are: .Redirect message congestion event. .Control message congestion event .DoS attack alert event. (TBD) 5. IP TML to meet TML Requirements This section defines how ForCES IP TML is specified to meet ForCES TML requirements. 5.1.Reliability This IP TML meets the reliability requirement by defining that PL control messages should be put in TCP, while PL redirect messages should be put in UDP in a TCP-UDP pair TML connection. Reliability of TCP like no packet loss, no reordering, and no corruption then maps to the reliability of PL control message transportation, but note that TCP does not grantee a timely transportation, therefore timeliness should be specifically addressed. The reason to mandate UDP for PL redirect messages is that: W. M. Wang Expires Jan., 2006 [Page 11] Internet Draft ForCES TML over IP July 2005 1. UDP provides relatively raw data transportation performance, which fits well in the cases where the application level of which may further be embedded with some Internet protocols like IP, UDP and even congestion awareness protocols like TCP protocol. Usually, redirect data may contain data that runs protocols like TCP, UDP, and IP. 2. UDP provides multicast mechanism. Redirect data generated by CE may often have to do multicast to many FEs, like some routing protocols may have to do for their messages. 5.2.Security (TBD) 5.3.Congestion Control and Protection against DoS Attacks Although PL control messages and redirect messages are transmitted separately over TCP and UDP, such separation itself does not provide congestion control and protection against DoS attacks from redirect data [GRMP-TEST]. In this IP TML, congestion control and protection against DoS attacks are provided by Arbiter Component (AC) running an algorithm for arbitrating PL messages. (TBD) 5.4.High Availability ForCES protocol has provided Heartbeat Messages specifically for CE/FE availability detection at PL layer, therefore TML layer does not need to take more care of CE/FE level availability. TML may take care of High Availability on TML connections. In this IP TML, every TML connection is a TCP-UDP pair connection. A TCP connection is connection-oriented and has provided connection management. Although UDP does not provide such connection management, the UDP is defined to have to associate to a TCP to form a TCP-UDP pair. As a Result, IP TML connections that are TCP-UDP pairs usually do not need to have extra means like heartbeat to detect its connection availability. 5.5.Multicast Multicast of PL messages at PL level should map to IP TML level with two different usage cases as below: . Multicast control messages from a CE to FEs or from a FE to CEs should map to multiple unicast TCPs at IP TML W. M. Wang Expires Jan., 2006 [Page 12] Internet Draft ForCES TML over IP July 2005 . Multicast redirect messages from a CE to FEs or from a FE to CEs should map to multicast UDP at IP TML The two multicast cases can further be divided into four more usage cases, according to the message transmission direction, from a CE to FEs or from FE to CEs. The four cases are describe in details as below: 1. Multicast control messages from a CE to FEs PL level multicast control messages from CE to FEs is mapped to IP TML by use of multiple unicast TCPs by the following steps: a. CE PL or its application layer above forms a CE->FEs multicast list as below: {FEgroupID, FEmemberID1, FEmemberID2, ...} Where, FEgroupID is the multicast FE group ID, followed by the FE members of the multicast. b. CE PL then sends the mulitcast list to the CE IP TML by TMLconfig service primitives. This TML configure information will go to the Arbiter Component (AC) at the IP TML. c. CE may also send the multicast list to related FEs by use of a PL CE->FE configure message as an attribute of the related FE protocol LFBs in the FEs. (Editor: when CE doing CE->FE multicast by use of multiple unicast TCPs, there seems no need for the FEs aware of such multicast list, therefore it maybe unnecessary for CE to send to FEs such multicast list.) d. When a CE PL control message marked with the FEgroupID as its destination FE ID arrives at the TML AC, the message will be distributed and transmitted by the AC to individual TML TCP connections according to the individual FE member IDs. e. At the FEs side, when PL messages marked with such multicast FE ID arrives at the FE AC, they are just delivered to the FE PL like a normal unicast PL message. 2. Multicast control messages from a FE to CEs PL level multicast control messages from FE to CEs is mapped to IP TML by use of multiple unicast TCPs. It is a little different from CE->FEs control message multicast in that the multicast establishment in this case should still be under the control of a CE (the CE should be the currently active CE and act as a master CE among several redundant CEs). The steps for this multicast is as follows: W. M. Wang Expires Jan., 2006 [Page 13] Internet Draft ForCES TML over IP July 2005 a. The active CE, whose PL or application layer above forms a FE->CE multicast list as: {CEgroupID, CEmemberID1, CEmemberID2, ...} Where, CEgroupID is the multicast CE group ID, followed by the CE members of the multicast. b. CE sends the multicast list to related FEs by use of a PL CE->FE configure message. A mulitcast list is treated as an attribute of a FE protocol LFB in a FE. c. When the FEs receive the multicast list, they just send the information further to their IP TMLs by use of TMLconfig service primitives. This TML configure information will go to the AC at the FEs’ IP TMLs. d. When a FE PL control message marked with the CEgroupID as its destination CE ID arrives at its FE IP TML, the message will be distributed and transmitted to individual TML TCP connections by the Arbiter Component (AC) in the TML according to the individual CE member IDs. d. At the group member CE side, when a PL message marked with a CEgroupID arrives at the CE, they are just delivered to the CE PL like a normal unicast PL messages by the AC in the CE TML. 3. Multicast redirect messages from a CE to FEs (TBD) 4. Multicast redirect messages from a FE to CEs (TBD) 5.6.Prioritization This IP TML can meet the different prioritization from PL level by use of several TCP-UDP pair connections between one same CE and one same FE. (TBD) 5.7.Encapsulation 1. TCP Encapsulation When ForCES PL messages are transported over TCP, a TCP port number or port numbers (if multiple TCP connections are established) that are specifically assigned for ForCES protocol use should be adpoted. The encapsulation format is as below: W. M. Wang Expires Jan., 2006 [Page 14] Internet Draft ForCES TML over IP July 2005 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 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TCP header with the port number for the ForCES protocol ~ | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ForCES PL Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. UDP Encapsulation When ForCES PL messages are transported over UDP protocol, a UDP port number that is specifically assigned to ForCES protocol should be used. The encapsulation format is as below: 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 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ UDP header with the port number for the ForCES protocol ~ | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ForCES PL Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. IP TML Messages (TBD) (Editor: In this IP TML, there maybe only two cases that need to use IP TML level messaging: 1. After a TCP connection is established between a CE and a FE, FE may need to further tell CE what this connection is used for. This maybe implemented by FE sending a TML message to CE to tell some information. This information may include something like the FE ID, the priorities this connection is used for. Based on this information, CMC in CE can establish the ”TML Connection Table” for CE PL to send PL messages according to the information. W. M. Wang Expires Jan., 2006 [Page 15] Internet Draft ForCES TML over IP July 2005 2. During the establishment of a mulitcast based on UDP, a UDP multicast group IP address that will map to a CE/FE groupID at PL level may need to be informed to all group members via a TML message, so as to establish a UDP multicast. ) 7. Security Considerations (TBD) 8. IANA Considerations The Following Assigned Numbers are considered: TCP Port Number(s) for ForCES Protocol UDP Port Number for ForCES protocol 9. References [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- ietf-forces-protocol-02.txt, work-in-progress, Feb. 2005. [ForCES-Model] Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z. and S. Blake, "ForCES Forwarding Element Model", October 2003, http://www.ietf.org/internet-drafts/draft-ietf-forces-model-03.txt. [ForCES-SP]J. Hadi, W. M. Wang, etc, ForCES TML Service Primitives, work in progress, draft- , [GRMP-TEST]L. Dong, L. Shi, and W. Wang, A Testbed for GRMP Protocol, Proceedings of 59th IETF Meeting, 2004, Feb.29-Mar.4, Seoul, Korea, http://www.ietf.org/proceedings/04mar/slides/forces-2.pdf 10. Author's Address Weiming Wang Zhejiang Gongshang University 149 Jiaogong Road Hangzhou 310035 P.R.China Phone: +86-571-88071024 EMail: wmwang@mail.zjgsu.edu.cn Ligang Dong Zhejiang Gongshang University 149 Jiaogong Road Hangzhou 310035 P.R.China Phone: +86-571-88071024 EMail: donglg@mail.zjgsu.edu.cn Intellectual Property Statement W. M. Wang Expires Jan., 2006 [Page 16] Internet Draft ForCES TML over IP July 2005 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. W. M. Wang Expires Jan., 2006 [Page 17]