idnits 2.17.1 draft-ietf-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 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 899. ** 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: ---------------------------------------------------------------------------- == 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.) -- The document date (April 2006) is 6585 days in the past. Is this intentional? 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 42, but not defined == Unused Reference: 'RFC3654' is defined on line 845, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3654 == Outdated reference: A later version (-22) exists of draft-ietf-forces-protocol-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'ForCES-Model' Summary: 8 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: October, 2006 J. Hadi Salim 4 Znyx Networks 5 April 2006 7 ForCES Transport Mapping Layer (TML) Service Primitives 9 draft-ietf-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 a variety of TMLs. 50 Table of Contents 52 1. Introduction....................................................2 53 2. Definitions.....................................................3 54 3. Overview........................................................3 55 3.1. ForCES Protocol Framework..................................3 56 3.2. TML Requirements...........................................4 57 4. TML Modeling....................................................5 58 4.1. TML events.................................................6 59 4.2. TML attributes.............................................9 60 4.3. TML capabilities..........................................12 61 5. Service Primitives.............................................13 62 5.1. Design Principles.........................................13 63 5.2. Objectives................................................13 64 5.3. TML Open..................................................13 65 5.4. TML close.................................................14 66 5.5. TML Configuration.........................................15 67 5.6. TML Query.................................................15 68 5.7. TML send..................................................16 69 5.8. TML receive...............................................17 70 6. Theory of Operation............................................17 71 7. References.....................................................17 72 8. Author's Address...............................................17 73 Appendix A. TML Attributes XML file...............................18 75 1. Introduction 77 The Forwarding and Control Element Separation (ForCES) is a proposed 78 architecture for network elements like routers, documents of which 79 include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the 80 ForCES FE model[ForCES-Model] that are work in progress. RFC3654 81 defines the ForCES requirements, RFC3746 defines the ForCES framework, 82 and the ForCES protocol defines the message exchange protocol between 83 the Forwarding Element (FE) and the Control Element (CE) in the 84 ForCES NE (see RFC3654 for the terminology definitions). 86 The ForCES protocol infrastructure consists of two components: 88 1. The Protocol Layer (PL), which is responsible for generating 89 ForCES protocol messages and also processing protocol messages that 90 come from peering protocol layers in the same ForCES NE. 92 Hadi Salim Expires Oct., 2006 [Page 2] 93 2. The Transport Mapping Layer (TML), which is responsible for 94 ForCES protocol message transports over variant transport media like 95 IP, Ethernet, ATM, etc. 97 The IETF ForCES protocol mainly defines the PL. TMLs according to 98 various transport media are also to be individually defined by IETF. 99 A ForCES PL implementation must be portable across all TMLs. It is 100 feasible that the implementers of TML and PL may be from different 101 organizations. As a result, there must be an interoperable method to 102 interconnect the PL and TML. A private method would make the PL and 103 TML implementations also private. 105 The purpose of this document is to present the method for an 106 interoperable interconnection of the PL and a variety of TMLs. 107 Although there might be other choices like using PL-TML messages, as 108 a more efficient way for data transmission and processing, a method 109 based on service primitives are recommended for interconnection of PL 110 and TML. In this document, a set of TML Service Primitives are 111 presented and related TML parameters are defined. Also presented in 112 the document is the theory of operation of PL-TML based on the 113 service primitives and the parameters. 115 2. Definitions 117 This document follows the terminology used by RFC3654, RFC3746, and 118 the ForCES protocol[ForCES-PL]. Some are just copied here: 120 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 121 architecture that defines the ForCES protocol messages, the protocol 122 state transfer scheme, as well as the ForCES protocol architecture 123 itself (including requirements of ForCES TML (see below). 124 Specifications of ForCES PL are defined by [ForCES-PL]. 126 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 127 ForCES protocol architecture that uses the capabilities of existing 128 transport protocols to specifically address protocol message 129 transportation issues, such as how the protocol messages are mapped 130 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 131 how to achieve and implement reliability, multicast, ordering, etc. 132 The ForCES TML specifications are detailed in separate ForCES 133 documents, one for each TML. 135 3. Overview 137 3.1. ForCES Protocol Framework 139 The ForCES protocol has presented the protocol framework as in 140 Figure 1. The framework shows the relationship between PL and TML. 141 According to this framework, TML lies under PL and provides services 142 to the PL. CE PL communicates with FE PL via CE TML and FE TML. On 144 Hadi Salim Expires Oct., 2006 [Page 3] 145 transmit, the PL delivers its ForCES messages to the TML. The TML 146 further delivers the message to the destination TML(s). On receive, 147 the TML delivers the ForCES messages it received to the PL. 149 +----------------------------------------------- 150 | CE PL layer | 151 +----------------------------------------------- 152 | CE TML layer | 153 +----------------------------------------------- 154 ^ 155 | 156 ForCES | 157 protocol | 158 messages | 159 | 160 | 161 | 162 v 163 +----------------------------------------------- 164 | FE TML layer | 165 +----------------------------------------------- 166 | FE PL layer | 167 +----------------------------------------------- 169 Figure 1 171 3.2. TML Requirements 173 The ForCES protocol [ForCES-PL] also presents TML requirements. We 174 list the requirements as below. These requirements are expected to be 175 delivered by TML using any kind of transport media, though the text 176 does not define how such mechanisms are delivered. Each TML must 177 describe how it contributes to achieving the requirements. If for any 178 reason a TML does not provide a service listed below a justification 179 needs to be provided. 181 The TML requirements are: 183 1. Reliability 184 As defined by RFC 3654, section 6 #6. 186 2. Security 187 TML provides security services to the ForCES PL. TML layer should 188 support the following security services and describe how they are 189 achieved. 191 * Endpoint authentication of FE and CE. 193 * Message Authentication 195 Hadi Salim Expires Oct., 2006 [Page 4] 196 * Confidentiality service 198 3. Congestion Control 199 The congestion control scheme used needs to be defined. The 200 congestion control mechanism defined by the TML should prevent the FE 201 from being overloaded by the CE or the CE from being overwhelmed by 202 traffic from the FE. Additionally, the circumstances under which 203 notification is sent to the PL to notify it of congestion must be 204 defined. 206 4.Uni/multi/broadcast addressing/delivery if any 207 If there is any mapping between PL and TML level Uni/Multi/Broadcast 208 addressing it needs to be defined. 210 5. HA decisions 211 It is expected that availability of transport links is the TML's 212 responsibility. However, on config basis, the PL layer may wish to 213 participate in link failover schemes and therefore the TML must 214 support this capability. 216 6. Encapsulations used. 217 Different types of TMLs will encapsulate the PL messages on 218 different types of headers. The TML needs to specify the 219 encapsulation used. 221 7. Prioritization 222 It is expected that the TML will be able to handle up to 8 priority 223 levels needed by the PL layer and will provide preferential treatment. 224 TML needs to define how this is achieved. The requirement for 225 supporting up to 8 priority levels does not mean that the underlying 226 TML MUST be capable of handling up to 8 priority levels. In such an 227 event the priority levels should be divided between the available TML 228 priority levels. For example, if the TML only supports 2 priority 229 levels, the 0-3 could go in one TML priority level, while 4-7 could 230 go in the other. 232 8. Protection against DoS attacks 233 As described in the Requirements RFC 3654, section 6 235 4. TML Modeling 237 To make PL capable of interconnection with variant TMLs in a 238 standardized way, the first work to do is to model the variant TMLs 239 in a uniform way from the perspective of a uniform PL. 241 Identical to modeling an LFB in an FE, from the perspective of PL, 242 TML properties can be abstracted by the following entities: 244 TML Events: 246 Hadi Salim Expires Oct., 2006 [Page 5] 247 The TML events that PL requires to know when the events happen in 248 the TML. 250 TML attributes: 251 The TML attributes that are required to be configured by PL 252 according to PL requirements. The attributes can also be queried by 253 PL. 255 TML capabilities: 256 The TML capabilities that PL are interested to know. 258 Note that, not all TML properties should be made perceivable by PL 259 from PL point of view. PL only cares those TML properties that are 260 common to all TMLs and that PL should interact with via service 261 primitives so that TML can work according to PL's requirements. 263 Via TML Service Primitives, PL should be able to access above 264 properties of variant TMLs. 266 4.1.TML events 268 There might be several TML events, but only some of them are PL must 269 sense via PL-TML interface. 271 A callback mechanism is defined for PL to sense the TML events by 272 PL-TML service primitives. PL first provides every event with a 273 callback function for the event processing in the PL. PL then tells 274 the callback handle to TML by service primitives. The callback handle 275 is usually stored in TML as a parameter. Whenever the relavent event 276 happens in TML, the TML triggers the handle to notify PL of the event. 277 PL executes the callback function, and asynchronously begins to 278 process the event. 280 After a TML event happened and PL is notified and a procedure to 281 process the event is executed, PL may be further interested in 282 knowing if the event status in the TML still exists or not. To meet 283 this requirement, an 'eventState' parameter is used in callback 284 functions to indicate if the reported is the event happened or the 285 event released. Whereas, not all events need to notify PL of their 286 release state. 288 The following TML events must be made to be notified by PL. If for 289 any reason a TML does not provide the service, a justification needs 290 to be provided in the TML specification. 292 1) TML failure event 294 This event happens when there is a TML failure. It is up to 295 individual TML specifications and even individual implementations to 297 Hadi Salim Expires Oct., 2006 [Page 6] 298 specify the detailed event triggering conditions, but usually, TML 299 failure should include the following cases: 300 . local TML link failure 301 . peer TML unavailable 302 . peer TML left 304 The different cases that cause the failure will be stated by a 305 failure code in the event callback function. 307 Callback handle for TML failure event is then defined as: 309 status = -- SUCCESS or errorIndication 310 callbackTMLFailureEvent( 311 IN eventState 312 IN failCode 313 ) 314 Where, 315 eventState = EventHAPPENED or EventRELEASED 316 failCode indicates the failure case 318 2) Message arrival event 320 TML can make it as an event when a PL ForCES protocol message coming 321 from peering TML arrives at the TML and the TML has made it ready for 322 PL to receive the message. In this way, an asynchronous message 323 receive mode can be realized in PL. In addition to this asynchronous 324 mode, PL can also use a specific TML receive service primitive 325 (defined below) for synchronous reception of PL messages. 327 Callback handle for message arrival event is defined as: 329 status = -- SUCCESS or errorIndication 330 callbackTMLMsgArrivalEvent( 331 IN msglen 332 IN msgPDU 333 ) 334 Where, msglen indicates the ForCES message length, and msgPDU is the 335 ForCES message body in its Protocol Data Unit format. There is no 336 need for message arrival event to notify a release state. 338 3) Control message congestion event 340 ForCES control messages are defined as all ForCES protocol messages 341 except ForCES redirect messages. ForCES redirect messages are 342 identified by the ForCES message types being marked as 343 'PacketRedirect'. 345 This event happens when the TML comes to a congestion state for the 346 control message transmission. It is up to individual TML 348 Hadi Salim Expires Oct., 2006 [Page 7] 349 specifications and even individual implementations to specify the 350 detailed event triggering conditions. 352 This event can be used by PL layer to monitor the control message 353 transmission. In FEs, this event may also be used to help monitoring 354 possible DoS attacks from redirected packets. 356 Callback handle for TML control message congestion event is defined 357 as: 359 status = -- SUCCESS or errorIndication 360 callbackTMLCtrMsgCongestEvent( 361 IN eventState 362 ) 363 Where, 364 eventState = EventHAPPENED or EventRELEASED 366 4)Redirect message congestion event 368 This event happens when the TML comes to a congestion state for the 369 PL redirect message transmission. It is up to individual TML 370 specifications and even individual implementations to specify the 371 detailed event triggering conditions. 373 This event can be used by PL layer to monitor the redirect message 374 transmission. In FEs, this may also be used to help monitoring 375 possible DoS attacks from redirect packets. 377 Callback handle for TML redirect message congestion event is defined 378 as: 380 status = -- SUCCESS or errorIndication 381 callbackTMLRedMsgCongestEvent( 382 IN eventState 383 ) 384 Where, 385 eventState = EventHAPPENED or EventRELEASED 387 5)DoS attack alert event 389 This event happens when the TML comes to a state that it feels there 390 are abnormal amount of PL redirect messages and there has made it 391 quite hard to transport PL control messages. Whereas, it is up to 392 individual TML specifications and even individual implementations to 393 specify the detailed and precise triggering conditions for the event. 395 This event is used by PL to monitor the security state for TML 396 message transmission. In FEs, when this event happens, usually FE PL 397 should trigger a DoS attack alert event to inform CE of the event. CE 398 may take further effects trying to prevent the attack. Note that, the 400 Hadi Salim Expires Oct., 2006 [Page 8] 401 event is an alert, when it happens, usually it does not mean the CE- 402 FE communication is totally lost. 404 Callback handle for TML DoS attack alert event is defined as: 406 status = -- SUCCESS or errorIndication 407 callbackTMLDoSAttackAlertEvent( 408 IN eventState 409 ) 410 Where, 411 eventState = EventHAPPENED or EventRELEASED 413 4.2.TML attributes 415 1) Event handles 417 Event handles are handles for PL to access events. An event callback 418 function handle is used as the purpose. Defining the handles as an 419 attribute of the TML, then, for PL to set the handle to TML is for 420 the PL to subscribe to the TML for the event notification, to delete 421 the handle from the TML is to unsubscribe the event from the TML. 423 We define the event handle TML attribute as below: 425 426 Eventhandle 427 Event callback handle 428 429 430 eventType 431 event type represented by an ID 432 uint16 433 434 435 TMLFailureEvent 436 TML failure event 437 438 439 TMLMsgArrivalEvent 440 TML ForCES message arrival event 441 442 443 TMLCtrMsgCongestEvent 444 445 TML ForCES congtrol message transmit congestion event 446 447 448 449 TMLRedMsgCongestEvent 450 452 Hadi Salim Expires Oct., 2006 [Page 9] 453 TML ForCES redirect message transmit congestion event 454 455 456 457 TMLDoSAttackAlertEvent 458 TML DoS attack alert event 459 460 461 462 463 handle 464 callback function handle of the event 465 uint64 466 467 468 470 471 EventHandles 472 event handle table in the TML 473 474 EventHandle 475 476 478 2)multicast lists 480 This attribute is used for TML to multicast ForCES messages. The 481 multicast list should be configured by PL, but individual TML 482 specifications should define how such multicast list maps to TML 483 transport level multicast mechanisms. 485 A PL level multicast list includes a group ID for the multicast and 486 a number of members of the multicast. The members are represented by 487 PL level protocol src/destIDs (include FE ID and CE ID). 489 Note that, there might be more than one multicast group for 490 multicast applications. The multiple multicast lists form a multicast 491 list table in TML. 493 The attribute for the multicast lists is defined as below: 494 } 495 496 McastList 497 498 a PL level multicast list for ForCES multicast transport 499 500 501 502 groupID 504 Hadi Salim Expires Oct., 2006 [Page 10] 505 32bits group ID of the multicast 506 uint32 507 508 509 members 510 511 members of the multicast represented by FE ID or CE ID 512 513 514 uint32 515 516 517 518 520 521 McastLists 522 523 a table representing several multicast lists in the TML 524 525 526 McastList 527 528 530 3) Working TML Type 532 A TML implementation may be capable of several TML transport ways. 533 For example, a TML with IP transport media may be able to support 534 several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In 535 this case, there should be a TML attribute describing the different 536 types and make PL able to switch among the types under the control of 537 CE. 539 The TML type is represented by an ID, defined as below: 541 542 TMLType 543 TML Type 544 545 uint16 546 547 548 TmlTcpUdp 549 TML uses TCP+UDP 550 551 552 TmlTcpDccp 553 TML uses TCP+DCCP 555 Hadi Salim Expires Oct., 2006 [Page 11] 556 557 558 TmlSctp 559 TML uses SCTP 560 561 562 TmlEth 563 TML uses Ethernet 564 565 566 TmlAtm 567 TML uses ATM 568 569 570 571 573 The TML attribute for the working TML type is defined as below: 575 576 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 Hadi Salim Expires Oct., 2006 [Page 12] 607 A TML implementation may be capable of several TML transport ways. 608 This capability indicates PL of the supported types. 610 The TML capability for the supported TML type is defined as below: 612 613 SupportedTMLType 614 supported TML types in the TML mechanism 615 616 TMLType 617 618 620 2) TML type configuration capability 622 623 TMLTypeConfigurable 624 TML Type configurable or not by PL 625 boolean 626 628 5. Service Primitives 630 5.1.Design Principles 632 Two principles are applied to this PL-TML service primitives design: 634 1.PL-TML service primitives should hide implementation details 635 regarding reliability, security, multicast, congestion control, etc 636 from PL. 638 2.PL-TML service primitives should avoid leading TML to read ForCES 639 protocol message PDU to get information, so as to immunize the TML 640 from the possible change of ForCES protocol PDU (like the protocol 641 update). 643 5.2.Objectives 645 There are several basic design objectives: 647 1. Support for unicast, multicast and broadcast PL level mechanisms. 648 2. support for both reliable and unreliable delivery. 649 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: 658 Hadi Salim Expires Oct., 2006 [Page 13] 659 status = -- SUCCESS or errorIndication 660 TMLopen( ) 662 Parameters: 663 none 665 Service Description: 666 The PL connects to the TML by invoking the TML open call. It highly 667 depends on the individual TML specifications what a TML should do 668 after receiving this call. For some TMLs, this primitive call may 669 only act as a signal to inform TML that PL is going to use the TML 670 for sending or receiving PL messages, while for some other TMLs, a 671 TML may have to do some TML level operation to prepare for PL usage 672 when receiving this primitive call. For example, For a connectionless 673 TML, this open primitive may does not have to do anything, while for 674 a connection-oriented TML, this open call may be a signal for the TML 675 to setup TML level connection(s) to peering TML(this actually means 676 the peer-to-peer TMLs do not have to always be connected after the 677 TML is initialized and during the post-association phase). 679 Another important point is, to better synchronize the operations 680 between peering PLs, the TML will have to discard all the PL messages 681 received from peering PL before the local TML has not yet been opened 682 by the local PL, 684 5.4. TML close 686 Syntax: 687 status = -- SUCCESS or errorIndication 688 TMLclose( ) 690 Parameters: 691 none 693 Service Description: 694 In this call, the PL disconnects from the TML. It highly depends on 695 the individual TML specifications what a TML should do after 696 receiving this call. For some TMLs, this primitive call may only act 697 as a signal to inform TML that PL is not going to use the TML for 698 sending or receiving PL messages anymore, while for some other TMLs, 699 a TML may have to do some extra TML level operations to disconnect it 700 to peering TMLs. For example, for a connectionless TML, this 701 primitive may do not have to do anything, while for a connection- 702 oriented TML, this primitive call may be a signal for the TML to 703 disconnect all TML level connections to peering TML. 705 Another important point is, to better synchronize the operations 706 between peering PLs, a TML will have to discard all PL messages 707 received by the TML after the TML has been closed by local PL. 709 Hadi Salim Expires Oct., 2006 [Page 14] 710 5.5.TML Configuration 712 Syntax: 713 status = -- SUCCESS or errorIndication 714 TMLconfig( 715 IN operation 716 IN path 717 IN data 718 ) 719 Parameters: 721 operation ?the operation type for the configuration. Two operations 722 are defined: 723 operation = ADD ?to add parameter 724 = DELETE ?to delete parameter 726 path ?a path composed of element ID(s) and (or) array index 727 pointing to the element to be configured. 728 (TBD) 730 data ?the data to be configured to the element. 731 (TBD) 733 Service Description: 734 This primitive is used by the PL to control the behavior of the TML 735 by the PL layer configuring the related property elements in the TML. 736 The element is indicated by the 'path'. The value to be configured to 737 the element is accessed by the 'data'. 739 5.6. TML Query 741 Syntax: 742 status = -- SUCCESS or errorIndication 743 TMLquery( 744 IN path 745 OUT data 746 ) 747 Parameters: 749 path ?a path composed of element ID(s) and (or) array index 750 pointing to the element to be queried. 751 (TBD) 753 data ?the data returned by the query. 754 (TBD) 756 Service Description: 758 Hadi Salim Expires Oct., 2006 [Page 15] 759 This primitive is used by the PL to query the behavior of the TML. 760 The querying element is indicated by the 'path'. The value queried is 761 stored at the 'data' field. The TML executes the primitive by filling 762 out the data field with the queried value of the element. 764 5.7. TML send 766 Syntax: 767 status = -- SUCCESS or errorIndication 768 TMLsend( 769 IN msgDestID, 770 IN msgType, 771 IN msgPrio, 772 IN msgLength, 773 IN msgPDU, 774 ) 776 Parameters: 777 msgDestID: the destination ID for the PL message to be sent 778 msgType: the message type for the PL message to be sent 779 msgPrio: the message priority for the PL message to be sent 780 msgLen: the message length to be sent 781 msgPDU: the ForCES protocol message to be sent in its PDU 783 Service Description: 784 In this service, the PL sends a message to one (unicast) or more 785 (multicast) peer PLs via the TML. Note that this primitive includes 786 all parameters that are necessary for TML to manage transmission of 787 the PL message, therefore, there is no need for the TML to read in 788 the PL message body to retrieve this parameters. In this way, we may 789 decouple changes in ForCES protocol PDU (e.g., by the protocol update) 790 from TML level. 792 The msgDestID is used for the TML to find out TML layer transport 793 addresses for the message transmission. It also includes the 794 processing for PL message multicast transports, for the destination 795 ID may also be a multicast group ID. 797 The msgType is used for the TML to infer the requirements from PL 798 level for the manage sending, regarding its reliability, timeliness, 799 security, and congestion control. With this message type, it is easy 800 to recognize PL redirect messages from PL control messages. 801 Individual TML specifications should define how the msgTypes are used 802 to map into the TML requirements. 804 The msgPrio is used for the TML to meet the PL requirement for the 805 message transmission priority; it may also be used for TML to meet 806 the TML requirements for reliability, timeliness, security, and 807 congestion control. Individual TML specifications should define how 809 Hadi Salim Expires Oct., 2006 [Page 16] 810 the priority is mapped into the TML transport mechanisms for 811 prioritized transmission. Individual TML specifications may also 812 define how the priority is used for other TML requirements. 814 5.8. TML receive 816 Syntax: 817 status = -- SUCCESS or errorIndication 818 TMLreceive( 819 IN msgLength, 820 IN msgPDU, 821 ) 823 Parameters: 824 msgLen: the length of the message received. 825 msgPDU: the received ForCES protocol message body in its PDU 826 format 828 Service Description: 829 This service is used for PL to synchronously receive PL messages 830 from peering TML. 832 Note that a PL message arrival event described before can also be 833 used for PL to receive PL messages from TML. The difference is that 834 this TML receive primitive makes PL to synchronously receive messages, 835 while a PL message arrival event receives messages in an asynchronous 836 way. Usually, an asynchronous method is more efficient in terms of 837 CPU cycles. 839 6. Theory of Operation 841 (TBD) 843 7. References 845 [RFC3654] Khosravi, et al., Requirements for Separation of IP 846 Control and Forwarding, RFC 3654, November 2003. 848 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- 849 ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006. 851 [ForCES-Model] Yang, L., ForCES Forwarding Element Model, Aug. 2003, 852 http://www.ietf.org/internet-drafts/draft-ietf-forces-model-05.txt. 854 8. Author's Address 856 Weiming Wang 857 Zhejiang Gongshang University 858 149 Jiaogong Road 859 Hangzhou 310035 861 Hadi Salim Expires Oct., 2006 [Page 17] 862 P.R.China 863 Phone: +86-571-88071024 864 EMail: wmwang@mail.zjgsu.edu.cn 866 Jamal Hadi Salim 867 Znyx Networks 868 195 Stafford Rd. West 869 Ottawa, Ontario 870 Canada 871 Email: hadi@znyx.com 873 Appendix A. TML Attributes XML file 875 (TBD) 877 Intellectual Property Statement 879 The IETF takes no position regarding the validity or scope of any 880 Intellectual Property Rights or other rights that might be claimed to 881 pertain to the implementation or use of the technology described in 882 this document or the extent to which any license under such rights 883 might or might not be available; nor does it represent that it has 884 made any independent effort to identify any such rights. Information 885 on the procedures with respect to rights in RFC documents can be 886 found in BCP 78 and BCP 79. 888 Copies of IPR disclosures made to the IETF Secretariat and any 889 assurances of licenses to be made available, or the result of an 890 attempt made to obtain a general license or permission for the use of 891 such proprietary rights by implementers or users of this 892 specification can be obtained from the IETF on-line IPR repository at 893 http://www.ietf.org/ipr. 895 The IETF invites any interested party to bring to its attention any 896 copyrights, patents or patent applications, or other proprietary 897 rights that may cover technology that may be required to implement 898 this standard. Please address the information to the IETF at ietf- 899 ipr@ietf.org. 901 Disclaimer of Validity 903 This document and the information contained herein are provided on 904 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 905 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 906 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 907 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 908 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 909 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 911 Hadi Salim Expires Oct., 2006 [Page 18] 912 Copyright Statement 914 Copyright (C) The Internet Society (2006). This document is subject 915 to the rights, licenses and restrictions contained in BCP 78, and 916 except as set forth therein, the authors retain all their rights. 918 Acknowledgment 920 Funding for the RFC Editor function is currently provided by the 921 Internet Society. 923 Hadi Salim Expires Oct., 2006 [Page 19]