idnits 2.17.1 draft-hadi-forces-tmlsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Security' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 55, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-forces-protocol-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'ForCES-Model' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ForCES Working Group W. M. Wang 2 Internet-Draft Zhejiang Gongshang Univ. 3 Expires: Augest, 2006 J. Hadi Salim 4 Znyx Networks 5 Feb. 2006 7 ForCES Transport Mapping Layer (TML) Service Primitives 9 draft-hadi-forces-tmlsp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 Abstract 45 This document proposes Service Primitives of Transport Mapping Layer 46 (TML) in a Forwarding and Control Element Separation(ForCES) network 47 element, to standardize the operations of ForCES Protocol Layer (PL) 48 to various types of TMLs. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 1. Introduction....................................................2 59 2. Definitions.....................................................3 60 3. Overview........................................................3 61 3.1. ForCES Protocol Framework..................................3 62 3.2. TML Requirements...........................................4 63 4. TML Modeling....................................................5 64 4.1. TML events.................................................6 65 4.2. TML attributes.............................................9 66 4.3. TML capabilities..........................................13 67 5. Service Primitives.............................................13 68 5.1. Design Principles.........................................13 69 5.2. Objectives................................................13 70 5.3. TML Open..................................................14 71 5.4. TML close.................................................14 72 5.5. TML Configuration.........................................15 73 5.6. TML Query.................................................15 74 5.7. TML send..................................................16 75 5.8. TML receive...............................................17 76 6. Theory of Operation............................................17 77 7. References.....................................................17 78 8. Author's Address...............................................17 79 Appendix A. TML Attributes XML file...............................18 81 1. Introduction 83 The Forwarding and Control Element Separation (ForCES) is a proposed 84 architecture for network elements like routers, documents of which 85 include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the 86 ForCES FE model[ForCES-Model] that are working in progress. RFC3654 87 defines the ForCES requirements, RFC3746 defines the ForCES framework, 88 and the ForCES protocol defines the message exchanging protocol 89 between the Forwarding Element (FE) and the Control Element (CE) in 90 the ForCES NE. 92 The ForCES protocol infrastructure constitutes of two components: 94 Hadi Salim Expires Augest, 2006 [Page 2] 95 1. The Protocol Layer (PL), which is responsible for generating 96 ForCES protocol messages and also processing protocol messages that 97 come from peering protocol layers in the same ForCES NE. 99 2. The Transport Mapping Layer (TML), which is responsible for 100 ForCES protocol message transports over variant transport media like 101 IP, Ethernet, ATM, etc. 103 The ForCES protocol, which mainly define the PL, is being worked to 104 be standardized by IETF. TMLs according to various transport media 105 are also to be individually standardized by IETF. A ForCES PL 106 implementation must be portable across all TMLs. It makes feasible 107 that the implementers of TML and PL maybe from different 108 organizations. As a result, there must be a standard method to 109 interconnect PL and TML. A private method would make the PL and TML 110 implementations also private. 112 The purpose of this document is to present the method that 113 standardize the interconnection of PL and variant TMLs. Although 114 there might be other choices like using PL-TML messages, as a more 115 efficient way for data transmission and processing, a method based on 116 service primitives are recommended for interconnection of PL and TML. 117 In this document, a set of TML Service Primitives are presented and 118 related TML parameters are defined. Also presented in the document is 119 the theory of operation of PL-TML based on the service primitives and 120 the parameters. 122 2. Definitions 124 This document follows the terminology used by the ForCES 125 protocol[ForCES-PL]. Some are just copied here: 127 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 128 architecture that defines the ForCES protocol messages, the protocol 129 state transfer scheme, as well as the ForCES protocol architecture 130 itself (including requirements of ForCES TML (see below). 131 Specifications of ForCES PL are defined by [ForCES-PL]. 133 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 134 ForCES protocol architecture that uses the capabilities of existing 135 transport protocols to specifically address protocol message 136 transportation issues, such as how the protocol messages are mapped 137 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 138 how to achieve and implement reliability, multicast, ordering, etc. 139 The ForCES TML specifications are detailed in separate ForCES 140 documents, one for each TML. 142 3. Overview 144 3.1. ForCES Protocol Framework 146 Hadi Salim Expires Augest, 2006 [Page 3] 147 The ForCES protocol has presented the protocol framework as in 148 Figure 1. The framework shows the relationship between PL and TML. 149 According to this framework, TML lies under PL and provides services 150 to the PL. CE PL communicates with FE PL via CE TML and FE TML. On 151 transmit, the PL delivers its ForCES messages to the TML. The TML 152 further delivers the message to the destination TML(s). On receive, 153 the TML delivers the ForCES messages it received to the PL. 155 +----------------------------------------------- 156 | CE PL layer | 157 +----------------------------------------------- 158 | CE TML layer | 159 +----------------------------------------------- 160 ^ 161 | 162 ForCES | 163 protocol | 164 messages | 165 | 166 | 167 | 168 v 169 +----------------------------------------------- 170 | FE TML layer | 171 +----------------------------------------------- 172 | FE PL layer | 173 +----------------------------------------------- 175 Figure 1 177 3.2. TML Requirements 179 The ForCES protocol [ForCES-PL] also presents TML requirements. We 180 list the requirements as below. These requirements are expected to be 181 delivered by TML using any kind of transport media, though the text 182 does not define how such mechanisms are delivered. Each TML must 183 describe how it contributes to achieving the requirements. If for any 184 reason a TML does not provide a service listed below a justification 185 needs to be provided. 187 The TML requirements are: 189 1. Reliability 190 As defined by RFC 3654, section 6 #6. 192 2. Security 194 Hadi Salim Expires Augest, 2006 [Page 4] 195 TML provides security services to the ForCES PL. TML layer should 196 support the following security services and describe how they are 197 achieved. 199 * Endpoint authentication of FE and CE. 201 * Message Authentication 203 * Confidentiality service 205 3. Congestion Control 206 The congestion control scheme used needs to be defined. The 207 congestion control mechanism defined by the TML should prevent the FE 208 from being overloaded by the CE or the CE from being overwhelmed by 209 traffic from the FE. Additionally, the circumstances under which 210 notification is sent to the PL to notify it of congestion must be 211 defined. 213 4.Uni/multi/broadcast addressing/delivery if any 214 If there is any mapping between PL and TML level Uni/Multi/Broadcast 215 addressing it needs to be defined. 217 5. HA decisions 218 It is expected that availability of transport links is the TML's 219 responsibility. However, on config basis, the PL layer may wish to 220 participate in link failover schemes and therefore the TML must 221 support this capability. 223 6. Encapsulations used. 224 Different types of TMLs will encapsulate the PL messages on 225 different types of headers. The TML needs to specify the 226 encapsulation used. 228 7. Prioritization 229 It is expected that the TML will be able to handle up to 8 priority 230 levels needed by the PL layer and will provide preferential treatment. 231 TML needs to define how this is achieved. The requirement for 232 supporting up to 8 priority levels does not mean that the underlying 233 TML MUST be capable of handling up to 8 priority levels. In such an 234 event the priority levels should be divided between the available TML 235 priority levels. For example, if the TML only supports 2 priority 236 levels, the 0-3 could go in one TML priority level, while 4-7 could 237 go in the other. 239 8. Protection against DoS attacks 240 As described in the Requirements RFC 3654, section 6 242 4. TML Modeling 244 Hadi Salim Expires Augest, 2006 [Page 5] 245 To make PL capable of interconnection with variant TMLs in a 246 standardized way, the first work to do is to model the variant TMLs 247 in a uniform way from the perspective of a uniform PL. 249 Identical to modeling an LFB in an FE, from the perspective of PL, 250 TML properties can be abstracted by the following entities: 252 TML Events: 253 The TML events that PL requires to know when the events happen in 254 the TML. 256 TML attributes: 257 The TML attributes that are required to be configured by PL 258 according to PL requirements. The attributes can also be queried by 259 PL. 261 TML capabilities: 262 The TML capabilities that PL are interested to know. 264 Note that, not all TML properties should be made perceivable by PL 265 from PL point of view. PL only cares those TML properties that are 266 common to all TMLs and that PL should interact with via service 267 primitives so that TML can work according to PL's requirements. 269 Via TML Service Primitives, PL should be able to access above 270 properties of variant TMLs. 272 4.1.TML events 274 There might be several TML events, but only some of them are PL must 275 sense via PL-TML interface. 277 A callback mechanism is defined for PL to sense the TML events by 278 PL-TML service primitives. PL first provides every event with a 279 callback function for the event processing in the PL. PL then tells 280 the callback handle to TML by service primitives. The callback handle 281 is usually stored in TML as a parameter. Whenever the relavent event 282 happens in TML, the TML triggers the handle to notify PL of the event. 283 PL executes the callback function, and asynchronously begins to 284 process the event. 286 After a TML event happened and PL is notified and a procedure to 287 process the event is executed, PL may be further interested in 288 knowing if the event status in the TML still exists or not. To meet 289 this requirement, an 'eventState' parameter is used in callback 290 functions to indicate if the reported is the event happened or the 291 event released. Whereas, not all events need to notify PL of their 292 release state. 294 Hadi Salim Expires Augest, 2006 [Page 6] 295 The following TML events must be made to be notified by PL. If for 296 any reason a TML does not provide the service, a justification needs 297 to be provided in the TML specification. 299 1) TML failure event 301 This event happens when there is a TML failure. It is up to 302 individual TML specifications and even individual implementations to 303 specify the detailed event triggering conditions, but usually, TML 304 failure should include the following cases: 305 . local TML link failure 306 . peer TML unavailable 307 . peer TML left 309 The different cases that cause the failure will be stated by a 310 failure code in the event callback function. 312 Callback handle for TML failure event is then defined as: 314 status = -- SUCCESS or errorIndication 315 callbackTMLFailureEvent( 316 IN eventState 317 IN failCode 318 ) 319 Where, 320 eventState = EventHAPPENED or EventRELEASED 321 failCode indicates the failure case 323 2) Message arrival event 325 TML can make it as an event when a PL ForCES protocol message coming 326 from peering TML arrives at the TML and the TML has made it ready for 327 PL to receive the message. In this way, an asynchronous message 328 receive mode can be realized in PL. In addition to this asynchronous 329 mode, PL can also use a specific TML receive service primitive 330 (defined below) for synchronous reception of PL messages. 332 Callback handle for message arrival event is defined as: 334 status = -- SUCCESS or errorIndication 335 callbackTMLMsgArrivalEvent( 336 IN msglen 337 IN msgPDU 338 ) 339 Where, msglen indicates the ForCES message length, and msgPDU is the 340 ForCES message body in its Protocol Data Unit format. There is no 341 need for message arrival event to notify a release state. 343 3) Control message congestion event 345 Hadi Salim Expires Augest, 2006 [Page 7] 346 ForCES control messages are defined as all ForCES protocol messages 347 except ForCES redirect messages. ForCES redirect messages are 348 identified by the ForCES message types being marked as 349 'PacketRedirect'. 351 This event happens when the TML comes to a congestion state for the 352 control message transmission. It is up to individual TML 353 specifications and even individual implementations to specify the 354 detailed event triggering conditions. 356 This event can be used by PL layer to monitor the control message 357 transmission. In FEs, this event may also be used to help monitoring 358 possible DoS attacks from redirected packets. 360 Callback handle for TML control message congestion event is defined 361 as: 363 status = -- SUCCESS or errorIndication 364 callbackTMLCtrMsgCongestEvent( 365 IN eventState 366 ) 367 Where, 368 eventState = EventHAPPENED or EventRELEASED 370 4)Redirect message congestion event 372 This event happens when the TML comes to a congestion state for the 373 PL redirect message transmission. It is up to individual TML 374 specifications and even individual implementations to specify the 375 detailed event triggering conditions. 377 This event can be used by PL layer to monitor the redirect message 378 transmission. In FEs, this may also be used to help monitoring 379 possible DoS attacks from redirect packets. 381 Callback handle for TML redirect message congestion event is defined 382 as: 384 status = -- SUCCESS or errorIndication 385 callbackTMLRedMsgCongestEvent( 386 IN eventState 387 ) 388 Where, 389 eventState = EventHAPPENED or EventRELEASED 391 5)DoS attack alert event 393 This event happens when the TML comes to a state that it feels there 394 are abnormal amount of PL redirect messages and there has made it 395 quite hard to transport PL control messages. Whereas, it is up to 397 Hadi Salim Expires Augest, 2006 [Page 8] 398 individual TML specifications and even individual implementations to 399 specify the detailed and precise triggering conditions for the event. 401 This event is used by PL to monitor the security state for TML 402 message transmission. In FEs, when this event happens, usually FE PL 403 should trigger a DoS attack alert event to inform CE of the event. CE 404 may take further effects trying to prevent the attack. Note that, the 405 event is an alert, when it happens, usually it does not mean the CE- 406 FE communication is totally lost. 408 Callback handle for TML DoS attack alert event is defined as: 410 status = -- SUCCESS or errorIndication 411 callbackTMLDoSAttackAlertEvent( 412 IN eventState 413 ) 414 Where, 415 eventState = EventHAPPENED or EventRELEASED 417 4.2.TML attributes 419 1) Event handles 421 Event handles are handles for PL to access events. An event callback 422 function handle is used as the purpose. Defining the handles as an 423 attribute of the TML, then, for PL to set the handle to TML is for 424 the PL to subscribe to the TML for the event notification, to delete 425 the handle from the TML is to unsubscribe the event from the TML. 427 We define the event handle TML attribute as below: 429 430 Eventhandle 431 Event callback handle 432 433 434 eventType 435 event type represented by an ID 436 uint16 437 438 TMLFailureEvent 440 TML failure event 441 442 TMLMsgArrivalEvent 444 TML ForCES message arrival event 445 446 TMLCtrMsgCongestEvent 449 Hadi Salim Expires Augest, 2006 [Page 9] 450 451 TML ForCES congtrol message transmit congestion event 452 453 454 TMLRedMsgCongestEvent 456 457 TML ForCES redirect message transmit congestion event 458 459 460 TMLDoSAttackAlertEvent 462 TML DoS attack alert event 463 464 465 466 467 handle 468 callback function handle of the event 469 uint64 470 471 472 474 EventHandles 476 event handle table in the TML 477 478 EventHandle 479 480 482 2)multicast lists 484 This attribute is used for TML to multicast ForCES messages. The 485 multicast list should be configured by PL, but individual TML 486 specifications should define how such multicast list maps to TML 487 transport level multicast mechanisms. 489 A PL level multicast list includes a group ID for the multicast and 490 a number of members of the multicast. The members are represented by 491 PL level protocol src/destIDs (include FE ID and CE ID). 493 Note that, there might be more than one multicast group for 494 multicast applications. The multiple multicast lists form a multicast 495 list table in TML. 497 The attribute for the multicast lists is defined as below: 498 } 499 500 McastList 501 502 a PL level multicast list for ForCES multicast transport 503 504 505 506 groupID 507 32bits group ID of the multicast 508 uint32 509 510 511 members 512 513 members of the multicast represented by FE ID or CE ID 514 515 516 uint32 517 518 519 520 522 McastLists 524 525 a table representing several multicast lists in the TML 526 527 528 McastList 529 530 532 3) Working TML Type 534 A TML implementation may be capable of several TML transport ways. 535 For example, a TML with IP transport media may be able to support 536 several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In 537 this case, there should be a TML attribute describing the different 538 types and make PL able to switch among the types under the control of 539 CE. 541 The TML type is represented by an ID, defined as below: 543 544 TMLType 545 TML Type 546 547 uint16 548 549 TmlTcpUdp 551 TML uses TCP+UDP 552 553 TmlTcpDccp 555 TML uses TCP+DCCP 556 557 TmlSctp 559 TML uses SCTP 560 561 TmlEth 563 TML uses Ethernet 564 565 TmlAtm 567 TML uses ATM 568 569 570 571 573 The TML attribute for the working TML type is defined as below: 575 WorkingTMLType 577 current working TML type assigned by PL 578 TMLType 579 581 Note that, the working TML type attribute may be configurable or may 582 only be readable depending on implementations. TML capability on the 583 TML type (defined below) will tell if it is configurable or not. To 584 query the TML type capability before configuring the working TML type 585 attribute will help to correctly configure it. 587 4) Media specific TML parameters 589 Individual TML may require configuring some TML parameters specific 590 to its TML media. There leave a space in TML service primitives for 591 such requirement. Individual TML specifications should provide 592 detailed definitions for such parameters. 594 5) Vendor specific TML parameters 596 Vendors of individual implementations of TML may require configuring 597 some TML parameters specific to its implementation. There leave a 598 space in TML service primitives for such requirement. Individual 599 implementation should provide detailed definitions for such 600 parameters. 602 4.3. TML capabilities 604 1) Supported TML type 606 A TML implementation may be capable of several TML transport ways. 607 This capability indicates PL of the supported types. 609 The TML capability for the supported TML type is defined as below: 611 SupportedTMLType 613 supported TML types in the TML mechanism 614 TMLType 616 617 619 2) TML type configuration capability 621 TMLTypeConfigurable 623 TML Type configurable or not by PL 624 boolean 625 627 5. Service Primitives 629 5.1.Design Principles 631 Two principles are applied to this PL-TML service primitives design: 633 1.PL-TML service primitives should hide implementation details 634 regarding reliability, security, multicast, congestion control, etc 635 from PL. 637 2.PL-TML service primitives should avoid leading TML to read ForCES 638 protocol message PDU to get information, so as to immunize the TML 639 from the possible change of ForCES protocol PDU (like the protocol 640 update). 642 5.2.Objectives 644 There are several basic design objectives: 646 1. Support for unicast, multicast and broadcast PL level mechanisms. 647 2. support for both reliable and unreliable delivery. 648 3. Support for in-order or agnostic delivery. 650 4. Support for timeliness requirements. 651 5. Support for both synchronous and asynchronous operations. 652 6. Support for event notifications from TML to PL. 654 5.3. TML Open 656 Syntax: 657 status = -- SUCCESS or errorIndication 658 TMLopen( ) 660 Parameters: 661 none 663 Service Description: 664 The PL connects to the TML by invoking the TML open call. It highly 665 depends on the individual TML specifications what a TML should do 666 after receiving this call. For some TMLs, this primitive call may 667 only act as a signal to inform TML that PL is going to use the TML 668 for sending or receiving PL messages, while for some other TMLs, a 669 TML may have to do some TML level operation to prepare for PL usage 670 when receiving this primitive call. For example, For a connectionless 671 TML, this open primitive may does not have to do anything, while for 672 a connection-oriented TML, this open call may be a signal for the TML 673 to setup TML level connection(s) to peering TML(this actually means 674 the peer-to-peer TMLs do not have to always be connected after the 675 TML is initialized and during the post-association phase). 677 Another important point is, to better synchronize the operations 678 between peering PLs, the TML will have to discard all the PL messages 679 received from peering PL before the local TML has not yet been opened 680 by the local PL, 682 5.4. TML close 684 Syntax: 685 status = -- SUCCESS or errorIndication 686 TMLclose( ) 688 Parameters: 689 none 691 Service Description: 692 In this call, the PL disconnects from the TML. It highly depends on 693 the individual TML specifications what a TML should do after 694 receiving this call. For some TMLs, this primitive call may only act 695 as a signal to inform TML that PL is not going to use the TML for 696 sending or receiving PL messages anymore, while for some other TMLs, 697 a TML may have to do some extra TML level operations to disconnect it 698 to peering TMLs. For example, for a connectionless TML, this 699 primitive may do not have to do anything, while for a connection- 700 oriented TML, this primitive call may be a signal for the TML to 701 disconnect all TML level connections to peering TML. 703 Another important point is, to better synchronize the operations 704 between peering PLs, a TML will have to discard all PL messages 705 received by the TML after the TML has been closed by local PL. 707 5.5.TML Configuration 709 Syntax: 710 status = -- SUCCESS or errorIndication 711 TMLconfig( 712 IN operation 713 IN path 714 IN data 715 ) 716 Parameters: 718 operation ?the operation type for the configuration. Two operations 719 are defined: 720 operation = ADD ?to add parameter 721 = DELETE ?to delete parameter 723 path ?a path composed of element ID(s) and (or) array index 724 pointing to the element to be configured. 725 (TBD) 727 data ?the data to be configured to the element. 728 (TBD) 730 Service Description: 731 This primitive is used by the PL to control the behavior of the TML 732 by the PL layer configuring the related property elements in the TML. 733 The element is indicated by the 'path'. The value to be configured to 734 the element is accessed by the 'data'. 736 5.6. TML Query 738 Syntax: 739 status = -- SUCCESS or errorIndication 740 TMLquery( 741 IN path 742 OUT data 743 ) 744 Parameters: 746 path ?a path composed of element ID(s) and (or) array index 747 pointing to the element to be queried. 748 (TBD) 749 data ?the data returned by the query. 750 (TBD) 752 Service Description: 754 This primitive is used by the PL to query the behavior of the TML. 755 The querying element is indicated by the 'path'. The value queried is 756 stored at the 'data' field. The TML executes the primitive by filling 757 out the data field with the queried value of the element. 759 5.7. TML send 761 Syntax: 762 status = -- SUCCESS or errorIndication 763 TMLsend( 764 IN msgDestID, 765 IN msgType, 766 IN msgPrio, 767 IN msgLength, 768 IN msgPDU, 769 ) 771 Parameters: 772 msgDestID: the destination ID for the PL message to be sent 773 msgType: the message type for the PL message to be sent 774 msgPrio: the message priority for the PL message to be sent 775 msgLen: the message length to be sent 776 msgPDU: the ForCES protocol message to be sent in its PDU 778 Service Description: 779 In this service, the PL sends a message to one (unicast) or more 780 (multicast) peer PLs via the TML. Note that this primitive includes 781 all parameters that are necessary for TML to manage transmission of 782 the PL message, therefore, there is no need for the TML to read in 783 the PL message body to retrieve this parameters. In this way, we may 784 decouple changes in ForCES protocol PDU (e.g., by the protocol update) 785 from TML level. 787 The msgDestID is used for the TML to find out TML layer transport 788 addresses for the message transmission. It also includes the 789 processing for PL message multicast transports, for the destination 790 ID may also be a multicast group ID. 792 The msgType is used for the TML to infer the requirements from PL 793 level for the manage sending, regarding its reliability, timeliness, 794 security, and congestion control. With this message type, it is easy 795 to recognize PL redirect messages from PL control messages. 797 Individual TML specifications should define how the msgTypes are used 798 to map into the TML requirements. 800 The msgPrio is used for the TML to meet the PL requirement for the 801 message transmission priority; it may also be used for TML to meet 802 the TML requirements for reliability, timeliness, security, and 803 congestion control. Individual TML specifications should define how 804 the priority is mapped into the TML transport mechanisms for 805 prioritized transmission. Individual TML specifications may also 806 define how the priority is used for other TML requirements. 808 5.8. TML receive 810 Syntax: 811 status = -- SUCCESS or errorIndication 812 TMLreceive( 813 IN msgLength, 814 IN msgPDU, 815 ) 817 Parameters: 818 msgLen: the length of the message received. 819 msgPDU: the received ForCES protocol message body in its PDU 820 format 822 Service Description: 823 This service is used for PL to synchronously receive PL messages 824 from peering TML. 826 Note that a PL message arrival event described before can also be 827 used for PL to receive PL messages from TML. The difference is that 828 this TML receive primitive makes PL to synchronously receive messages, 829 while a PL message arrival event receives messages in an asynchronous 830 way. Usually, an asynchronous method is more efficient in terms of 831 CPU cycles. 833 6. Theory of Operation 835 (TBD) 837 7. References 839 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- 840 ietf-forces-protocol-06.txt, work-in-progress, Dec. 2005. 842 [ForCES-Model] Yang, L., "ForCES Forwarding Element Model", Aug. 843 2003, http://www.ietf.org/internet-drafts/draft-ietf-forces-model- 844 05.txt. 846 8. Author's Address 847 Weiming Wang 848 Zhejiang Gongshang University 849 149 Jiaogong Road 850 Hangzhou 310035 851 P.R.China 852 Phone: +86-571-88071024 853 EMail: wmwang@mail.zjgsu.edu.cn 855 Jamal Hadi Salim 856 Znyx Networks 857 195 Stafford Rd. West 858 Ottawa, Ontario 859 Canada 860 Email: hadi@znyx.com 862 Appendix A. TML Attributes XML file 864 (TBD) 866 Intellectual Property Statement 868 The IETF takes no position regarding the validity or scope of any 869 Intellectual Property Rights or other rights that might be claimed to 870 pertain to the implementation or use of the technology described in 871 this document or the extent to which any license under such rights 872 might or might not be available; nor does it represent that it has 873 made any independent effort to identify any such rights. Information 874 on the procedures with respect to rights in RFC documents can be 875 found in BCP 78 and BCP 79. 877 Copies of IPR disclosures made to the IETF Secretariat and any 878 assurances of licenses to be made available, or the result of an 879 attempt made to obtain a general license or permission for the use of 880 such proprietary rights by implementers or users of this 881 specification can be obtained from the IETF on-line IPR repository at 882 http://www.ietf.org/ipr. 884 The IETF invites any interested party to bring to its attention any 885 copyrights, patents or patent applications, or other proprietary 886 rights that may cover technology that may be required to implement 887 this standard. Please address the information to the IETF at ietf- 888 ipr@ietf.org. 890 Disclaimer of Validity 892 This document and the information contained herein are provided on 893 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 894 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 895 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 896 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 900 Copyright Statement 902 Copyright (C) The Internet Society (2006). This document is subject 903 to the rights, licenses and restrictions contained in BCP 78, and 904 except as set forth therein, the authors retain all their rights. 906 Acknowledgment 908 Funding for the RFC Editor function is currently provided by the 909 Internet Society.