idnits 2.17.1 draft-ietf-forces-tmlsp-01.txt: -(811): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1214. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 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 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 207 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 337 has weird spacing: '...failure peer ...' == Line 340 has weird spacing: '...ly left peer...' == Line 483 has weird spacing: '...nstance routi...' -- 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 41, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 == Outdated reference: A later version (-22) exists of draft-ietf-forces-protocol-08 == Outdated reference: A later version (-16) exists of draft-ietf-forces-model-06 Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ForCES Working Group W. M. Wang 3 Internet-Draft Zhejiang Gongshang Univ. 4 Expires: August, 2007 J. Hadi Salim 5 Znyx Networks 6 Alex Audu 7 Garland SoftWorx 8 February, 2007 10 ForCES Transport Mapping Layer (TML) Service Primitives 12 draft-ietf-forces-tmlsp-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 Abstract 44 This document specifies Transport Mapping Layer (TML) Service 45 Primitives for Forwarding and Control Element Separation (ForCES). 46 Based on the service primitives, TML services that are provided by 47 TML to ForCES Protocol Layer (PL) are standardized. To define the 48 primitives, TML properties represented as TML events, TML attributes, 49 and TML capabilities are also specified in the document. 51 Table of Contents 53 1. Introduction....................................................2 54 2. Definitions.....................................................3 55 3. Overview........................................................3 56 3.1. ForCES Protocol Framework..................................3 57 3.2. TML Requirements...........................................4 58 4. TML Representation..............................................5 59 4.1. TML events.................................................6 60 4.2. TML attributes............................................11 61 4.3. TML capabilities..........................................14 62 5. TML Service Primitives.........................................15 63 5.1. Design Principles.........................................15 64 5.2. TML Open..................................................15 65 5.3. TML close.................................................16 66 5.4. TML Configuration.........................................17 67 5.5. TML Query.................................................18 68 5.6. TML send..................................................20 69 5.7. TML receive...............................................21 70 6. Operation Notes................................................22 71 7. Security Considerations........................................23 72 8. Acknowledgements...............................................24 73 9. References.....................................................24 74 10. Author's Address..............................................24 76 1. Introduction 78 ForCES aims to define a set of specifications for routers, firewalls, 79 gateways, etc based on the architecture of separation of Forwarding 80 Elements (FEs) and Control Elements (CEs). RFC3654 has presented the 81 ForCES requirements, and RFC3746 has defined the ForCES framework. 82 The ForCES FE model [ForCES-Model] is specifying the model to 83 represent an FE. The ForCES protocol [ForCES-PL] is specifying the 84 information exchanging protocol between CE and FE. 86 The ForCES protocol infrastructure consists of two layers: 88 1. The Protocol Layer (PL), which is responsible for generating 89 ForCES protocol messages, and processing protocol messages that come 90 from peering protocol layer in the same ForCES NE. 92 2. The Transport Mapping Layer (TML), which is responsible for 93 transportation of ForCES protocol messages over variant transport 94 media, like IP, Ethernet, ATM, etc. 96 The ForCES protocol [ForCES-PL] document defines the specifications 97 for PL, while TMLs of different transport media types are to be 98 defined by individual IETF documents. A ForCES PL implementation must 99 be portable across all TMLs. It is feasible that the implementers of 100 TML and PL may be from different organizations. As a result, services 101 TML provides to PL must be specified in a standardizing way. 103 The purpose of this document is to specify the services that various 104 TMLs must provide for ForCES PL layer. The TML services are 105 represented by a set of TML service primitives and associated TML 106 properties (TML attributes, etc). 108 Note that this document specifies TML services more at a semantic 109 level, i.e., it does not try to specify details on how the defined 110 TML services shall be implemented. Different Operating System 111 platforms that PL and TML may rely on to be developed may have 112 different programming methods, process techniques, data structures, 113 etc for realizing the set of TML services. As a result, TML interface 114 APIs constructed according to this document may vary in some way. In 115 this condition, one PL portable to various TMLs actually means the PL 116 must provide various interface drivers for different TMLs, while 117 keeping the PL kernel the same for the TML operations. 119 2. Definitions 121 This document follows the terminology used by RFC3654, RFC3746, the 122 ForCES protocol[ForCES-PL], and the ForCES FE model [ForCES-Model]. 123 For convenience, some definitions are just copied here: 125 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 126 architecture that defines the ForCES protocol messages, the protocol 127 state transfer scheme, as well as the ForCES protocol architecture 128 itself (including requirements of ForCES TML (see below). 129 Specifications of ForCES PL are defined by [ForCES-PL]. 131 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 132 ForCES protocol architecture that uses the capabilities of existing 133 transport protocols to specifically address protocol message 134 transportation issues, such as how the protocol messages are mapped 135 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 136 how to achieve and implement reliability, multicast, ordering, etc. 137 The ForCES TML specifications are detailed in separate ForCES 138 documents, one for each TML. 140 3. Overview 142 3.1. ForCES Protocol Framework 143 The ForCES protocol document has presented the protocol framework as 144 in Figure 1. The framework shows the relationship between Protocol 145 Layer (PL) and Transport Mapping Layer (TML). According to this 146 framework, TML lies under PL and provides transportation services for 147 protocol messages to PL. CE PL communicates with FE PL via CE TML 148 and FE TML. On transmission, PL delivers its ForCES messages to its 149 TML. The TML further delivers the messages to the destination peering 150 TML(s). On receive, TML delivers ForCES messages it has received to 151 its PL. 153 +-------------------+ +-------------------+ 154 | CE PL layer | | FE PL layer | 155 +-------------------+ +-------------------+ 156 | CE TML layer | | FE TML layer | 157 +-------------------+ +-------------------+ 158 ^ ^ 159 | ForCES protocol messages | 160 +--------------------------------------+ 162 Figure 1. ForCES Protocol Framework 164 3.2. TML Requirements 166 The ForCES protocol docuement has also presented TML requirements. 167 We list the requirements as below. Each TML specification must 168 describe how it contributes to achieving the requirements. If, for 169 any reason, a TML does not provide a service listed by the 170 requirements, a justification needs to be provided. 172 The TML requirements are: 174 1. Reliability 175 As defined by RFC 3654, section 6 #6. 177 2. Security 178 TML provides security services to the ForCES PL. TML layer should 179 support the following security services and describe how they are 180 achieved. 182 * Endpoint authentication of FE and CE. 184 * Message Authentication 186 * Confidentiality service 188 3. Congestion Control 189 The congestion control scheme used needs to be defined. The 190 congestion control mechanism defined by the TML should prevent the FE 191 from being overloaded by the CE or the CE from being overwhelmed by 192 traffic from the FE. Additionally, the circumstances under which 193 notification is sent to the PL to notify it of congestion must be 194 defined. 196 4.Uni/multi/broadcast addressing/delivery if any 197 If there is any mapping between PL and TML level Uni/Multi/Broadcast 198 addressing it needs to be defined. 200 5. HA decisions 201 It is expected that availability of transport links is the TML's 202 responsibility. However, on config basis, the PL layer may wish to 203 participate in link failover schemes and therefore the TML must 204 support this capability. 206 6. Encapsulations used. 207 Different types of TMLs will encapsulate the PL messages on 208 different types of headers. The TML needs to specify the 209 encapsulation used. 211 7. Prioritization 212 It is expected that the TML will be able to handle up to 8 priority 213 levels needed by the PL layer and will provide preferential treatment. 214 TML needs to define how this is achieved. The requirement for 215 supporting up to 8 priority levels does not mean that the underlying 216 TML MUST be capable of handling up to 8 priority levels. In such an 217 event the priority levels should be divided between the available TML 218 priority levels. For example, if the TML only supports 2 priority 219 levels, the 0-3 could go in one TML priority level, while 4-7 could 220 go in the other. 222 8. Protection against DoS attacks 223 As described in the Requirements RFC 3654, section 6 225 4. TML Representation 227 The document is to define a set of general services for TML that 228 various TMLs and their implementations must fundamentally provide for 229 ForCES PL layer. For this sake, a TML representation is necessary 230 that describes general properties of various TMLs. The following 231 entities are used to represent various TML properties. 233 TML Events: 234 When the events happen in TML, PL may be interested to be notified. 236 TML attributes: 237 Represent the TML parameters that should be configured by PL when PL 238 asks TML to provide services. 240 TML capabilities: 241 TML abilities or capacities that PL is interested to know. 243 Note that, not all TML properties should be made perceivable and 244 controllable by PL. PL only cares those TML properties that PL should 245 interact with in order for TML to properly provide services to the PL. 247 4.1. TML events 249 TML events are triggered by some TML status changes when TML is 250 running. PL layer may be interested to be notified when some TML 251 events occur. TML is responsible to asynchronously notify PL of these 252 events. 254 How a TML event is asynchronously notified to PL highly depends upon 255 operating system environments PL and/or TML implementations may be 256 based. As an example, some environments may adopt a callback 257 mechanism for notification of events between program processes. In 258 this case and for the PL/TML usage, PL may first construct a callback 259 function to process every event, and then tell TML the callback 260 function handle. Whenever an interested event happens in TML, the TML 261 will notify PL of the event by invoking the callback handle and let 262 PL execute the callback function. In this way, the TML asynchronously 263 passes the event notification to the PL. 265 However, this document does not try to define specific means for 266 PL/TML notification. Any appropriate means can be adopted under 267 condition that it shall meet the service requirements. 269 A TML event may appear as a sustained event, i.e., the event will 270 last until the condition triggered the event is changed and the event 271 is then released. For instance, when an error happens in TML, it will 272 last until the error is finally by any means removed. In the 273 sustained event case, PL may be interested in knowing not only when 274 the event takes place, but also when the event is released. To meet 275 this need, an event status parameter should be defined and associated 276 with a sustained event report. The parameter will mark the associated 277 event with either 'occurring' or 'is released' to indicate the two 278 different status of a sustained event. Nevertheless, not all events 279 are sustained events, so that not all event reports need this kind of 280 parameters. 282 A TML event shall be distinguished as being subscription-free or 283 subscription-requested. A subscription-free TML event will inevitably 284 be notified to PL when it occurs. A subscription-requested TML event 285 is only notified to PL when it has been subscribed for by the PL. A 286 way for PL to subscribe for a subscription-requested TML event will 287 be provided by defining an event handle TML attribute as in 1) of 288 Section 4.2. The TML attribute can also provide more events 289 parameters configuration. See Section 4.2 for more details on the 290 attribute definition. 292 An TML event is assigned a TML event id, so that PL can identify the 293 event uniquely. 295 Followed are descriptions of TML events that must be available for 296 all TML specifications. If, for any reason, an individual TML 297 specification does not provide the events, a justification needs to 298 be provided in the specification. 300 1) TML error event 302 This event reports a TML error during TML running to PL. When the 303 event is invoked, something might be wrong in the TML. Failures like 304 TML link failure in TML are also taken as TML errors, which can be 305 understood as fatal errors for some cases. 307 When the event occurs and an event report is notified to PL, an 308 error code is associated with the event report so as to pass more 309 information about the error to PL layer. The code may expose PL the 310 reason of the error, the type of the error, as such. 312 TML error event is a subscription-free event. When the event occurs, 313 it will always invoke a report to PL. 315 TML error event is a sustained event. The error status will last 316 until the error is removed by any means. 318 As a result, when the event is notified to PL, the following 319 information shall be associated with the event report: 321 o TML error code and associated data 323 o event status 324 1 The event is occurring 325 0 The event is released 327 Note that it is not restricted that more information may also be 328 associated with the event report, depending upon each TML 329 specification or implementation. 331 This document defines the following TML errors and associated data. 332 These errors are usually common to all types of TMLs. 334 TML error code TML error Associated Data 336 1 all local TML link failure none 337 2 some local TML link failure peer TML CE/FE ID(s) the 338 link is connected 339 3 peer TML unavailable peer TML CE/FE ID(s) 340 4 peer TML abnormally left peer TML CE/FE ID(s) 342 Each TML specification may define its specific errors. There is also 343 a room for each TML implementation to define specific errors. 345 TML error event is assigned with a TML event id = 1. 347 2) Message arrive event 349 TML shall be able to make it as an event occurrence when it has 350 received a PL ForCES protocol message from peer TML and has made it 351 ready to deliver to local PL. In this way, an asynchronous message 352 receive mode can be realized in PL. In addition to this asynchronous 353 mode, PL can also use a specific TML receive service primitive as 354 defined in Section 5.8 for PL synchronous receiving of ForCES 355 messages. 357 This event is a subscription-requested event, i.e, unless PL has 358 requested TML to do so, TML will not use an asynchronous event 359 notification way to deliver arrived messages to PL. In this case, PL 360 can still use a TML receive primitive to receive ForCES messages. 362 When the event is notified to PL, the following information shall be 363 associated: 365 o the arrived ForCES message length 367 o the whole arrived ForCES message Protocol Data Unit (PDU) 369 It is not restricted that other information might also be associated 370 with this event report, depending upon requirements of individual TML 371 specifications or implementations. 373 Note that the message arrive event is not a sustained event, and 374 there is no need to distinguish its status as occurring or released. 375 When the message is reported to PL, the event is automatically 376 released. 378 TML message arrive event is assigned with TML event id = 2. 380 3) TML congestion alert 382 Although it is expected that TML provide a ForCES message 383 transportation free of congestion, as a general problem for current 384 Internet society, congestion problem is still quite hard to be 385 completely avoided if mechanisms are purely limited in TML resources 386 and without help from PL resources. In many cases, with the help from 387 the resources in PL layer, congestion problem may be much better 388 suppressed. For example, in cases where the OS a TML adopts is 389 capable of detecting an ECN (Early/explicit congestion notification) 390 where the underlying IP protocol is capable of passing information to 391 the application, then the TML could pass such information to the PL. 392 The PL could use this information for example to adjust its sending 393 rates or increase or reduce the priority of certain PL messages, etc. 394 More over, even in the case PL could help little for TML congestion, 395 it is still very helpful for PL to know the TML congestion state if 396 it does happen. As a result, in the TML requirement in Section 3.2, 397 it is required that TML must be defined with a method to notify PL of 398 congestion state. 400 This document specifies that a TML congestion alert event must be 401 supplied with various TMLs and their implementations if the TMLs and 402 implementations are not free from congestion problems due to any 403 reasons. TML notifies PL of congestion state by this TML congestion 404 alert event. It is an alert event because we expect that TML notifies 405 PL of the event when TML is in danger of, rather than in the state of, 406 congestion. An alert event is more helpful, because TML is the only 407 path that an FE is connected to CE, and a complete congestion state 408 in TML may lead to CE lost control of the FE, which is fatal for the 409 FE. 411 A TML congestion alert event is defined as a subscription-requested 412 event. It means PL will subscribe for it if PL requires the 413 congestion alert. During some usage cases or during some period of 414 usage, PL may not be interested to be notified of such event. For 415 instance, in many cases, congestion problem at CE side are not so 416 serious as that at FE side where FE side often risk DoS attacks from 417 redirect data. In this case, CE side congestion alert event may be 418 turned off so as to save CPU resources, while FE side congestion 419 alert is always open. 421 A TML congestion alert event is a sustained event. When congestion 422 alerts, it will last until its state is changed back to free of 423 danger for congestion. TML should notify PL twice for the whole 424 congestion report. When there is a congestion alert, TML sends one 425 notification to PL, when it is released, TML sends another 426 notification to PL. 428 TML congestion alert event is assigned with TML event id = 3. 430 When the event is notified to PL, the following information will be 431 associated with its report: 433 o TML congestion alert type 434 1 congestion alert from control message transmission 435 2 congestion alert from redriect message transmission 436 3 alert from redirect DoS attack 437 o event status 438 1 The event is happening 439 0 The event is released 441 Note that it is not restricted that other information may also be 442 associated with the congestion alert report, depending upon 443 individual TML specifications or implementations. For instance, in 444 several cases, it may be of great help to associate with some extra 445 information as which CE/FE link is the congestion located. However, 446 it may be quite difficult for all TMLs and implementations to provide 447 such information, therefore, as a more suitable choice, it is just 448 left each TML or implementation to decide. 450 More specific definitions of the three types of TML congestion alerts 451 are presented as below: 453 1. Congestion alert from control message transmission 455 We define that ForCES control messages are all kinds of ForCES 456 protocol messages but ForCES redirect messages. ForCES message types 457 are identified by the message type in the ForCES message header. 458 ForCES redirect messages are the messages whose types are marked as 459 'PacketRedirect'[ForCES-PL]. ForCES redirect messages are used to 460 load redirect data between FE and CE. 462 Congestion alert from control message transmission indicates that TML 463 is in a state where control message transmission channel is in danger 464 of congestion and control messages is becoming hard to be transmitted 465 to peering TML(s). Individual TML specifications or implementations 466 may specifically define the detailed invoking state for the alert. 468 Because ForCES control messages are vital for ForCES network elements 469 to properly work, the congestion alert from control message 470 transmission is an important signal for PL to timely take actions to 471 secure the network element. 473 2. Congestion alert from redirect message transmission 475 This congestion alert is invoked when the TML comes to a risk that 476 redirect messages are congested during transmission. Each TML 477 specification or implementation may specifically define the detailed 478 invoking state for the alert. 480 ForCES redirect messages that load redirect data between FE and CE, 481 congestion of which may not be so harmful as that of ForCES control 482 messages, but some redirected data are still vital for ForCES network 483 elements to properly work. For instance routing protocol messages 484 are shipped via ForCES redirect messages. A long time congestion of 485 the messages will severely affect actions of routing protocols. Hence, 486 this congestion alert should be used by PL to avoid redirect message 487 congestion as much as possible to improve performance of whole 488 network elements. 490 3. Alert from redirect DoS attack 492 As described, ForCES redirect messages ship redirect data. In FEs, 493 redirect data come via FE interfaces from outer networks. This may 494 leave a hole for malicious attackers [RFC3654, RFC3746]. Attackers 495 may try to start a DoS attack by initiating huge amount of redirect 496 data to some specific ForCES CE. It may make some FE TML abnormally 497 busy transporting redirect data. Because TML channels for ForCES 498 redirect messages and ForCES control messages are often intervened in 499 many TML implementations in the same physical links, it may 500 eventually making control messages transmission blocked by redirect 501 messages transmission, making the network element in a denial of 502 service state. 504 This alert is used to indicate an alert for redirect DoS attack. Each 505 TML specification or implementation will specifically define the 506 actual invoking state or take a mechanism for the alert to be invoked, 507 or make a justification if the TML is considered free from such DoS 508 attack. If a TML has taken some specific mechanism to make 509 straightforward detection of DoS attacks from redirect data, this 510 alert may just be a result report of the DoS detection. 512 The TML alert from redirect DoS attack may not be sufficient enough 513 for the PL to assure the DoS attack state. PL may synthesize 514 information from other part of the FE, like information from some FE 515 LFBs, to finally decide it. Whereas, this alert has already been an 516 enough signal for PL to go into some urgent state for the whole 517 system security. Approaches should be taken immediately by PL to try 518 to release the alert state so that the FE is not in a risk of losing 519 control from CE. 521 4.2.TML attributes 523 TML attributes usually represent those TML parameters that need to be 524 configured by PL. To represent them as TML attributes, PL can then 525 use TML configuration service primitive as defined in Section 5.5 to 526 make operations to the parameters. PL can then also use TML query 527 service primitive defined in Section 5.6 to retrieve the status of 528 the parameters. 530 Every TML attribute shall be assigned with a unique id for PL to 531 identify the attribute. The id is called TML attribute id. 533 Followed are descriptions of basic TML attributes that shall be used 534 by all TMLs. Each TML or implementation may provide more detailed 535 definitions of these TML attributes based on the basic descriptions. 536 Individual TMLs or implementations are also allowed to define more 537 specific TML attributes on their own if necessary. 539 1) TML event handle 540 This TML attribute is used for PL to set some parameters for 541 individual TML events. Each TML may individually define its data 542 structure for this attribute, whereas, the data structure may have to 543 appear as a list and every element of the list may have to at least 544 include the following information: 546 o TML event id 547 This id acts as an index for individual TML events. 549 o subscription flag, if described is a subscription-requested TML 550 event 551 This flag is to indicate the state for TML event subscription. To 552 subscribe/unsubscribe an event is to set/reset the flag. 554 The attribute may also include other information for each TML event 555 implementation. For instance, for an implementation that adopts a 556 callback mechanism for event notifications, the attribute may include 557 a callback handle, which is used for PL to tell TML the callback 558 function handle. 560 The 'TML event handle' is assigned with a TML attribute id = 1. 562 2) Multicast list 564 ForCES protocol requires that TML must support for ForCES message 565 delivery in multicast ways. This multicast is defined at ForCES PL 566 level, i.e., to multicast a ForCES protocol message, a multicast 567 'Destination ID' at the ForCES message header will be specified (See 568 [ForCES-PL] for more details). To support the PL level multicast, TML 569 must be told the members of the multicast, so that the TML can 570 accordingly deliver messages to all the multicast members. A 571 multicast list is used for this purpose. The multicast list comprises 572 a multicast id, which is exactly the multicast 'Destination ID', and 573 numerous associated members, which are also represented by ForCES 574 'Destination ID's, represented as below: 576 multicast list = {multicast id, member1, member2, ... memberN} 578 When TML is told this multicast list, it means whenever TML is asked 579 by PL to send a ForCES message whose Destination ID is this multicast 580 id, the TML must deliver the message to all destination CEs or FEs 581 whose ids are individually represented by member1, member2, ... , and 582 memberN. Individual TML specifications should define how such 583 multicast list maps to TML transport level multicast mechanisms. For 584 instance, if TML adopts multiple TCP links for this PL level 585 multicast, every member in the multicast list may be mapped to a 586 specific TCP port and an associated IP address. If TML adopts UDP 587 multicast for this PL level multicast, a UDP multicast group with the 588 same numbers may be constructed and the multicast is mapped to the 589 UDP multicast group. 591 The multicast list must be set into TML by PL, hence it is defined 592 as a TML attribute. PL sets up the attribute by use of a TML 593 configuration service primitive. 595 There might be several multicast lists set to a TML so as to 596 construct multiple multicast paths for PL in this TML. The multicast 597 lists may form a table then in the TML. In this case, a multicast id 598 in every multicast list may act as an index for access of the table. 600 The 'TML multicast list' is assigned with a TML attribute id = 2. 602 3) Working TML Type 604 A TML implementation may be capable of several TML transport ways. 605 For example, a TML with IP transport media may be able to support TML 606 schemes as TCP for control messages transmission and DCCP for 607 redriect message transmission, or TCP for control messages and UDP 608 for redirect messages. In this case, it may be helpful for PL to 609 dynamically specify which TML transport scheme to adopt for current 610 work. 612 The working TML type is used for above purpose. It is defined as an 613 TML attribute. 615 It should be noted that, in many cases, PL does not have to manage 616 working TML type. TML may more rely on its own management tool or a 617 CE/FE manager for TML type management. As a result, this TML 618 attribute is defined as an optional TML attribute, i.e., it is 619 allowed that a TML may not provide this TML attribute for PL. 621 Whereas if the attribute is provided, it should include the 622 following information: 624 o Working TML Type id 625 the TML type represented by an id, which is set to the TML for it 626 works in this type. The TML type id may be assigned with one of the 627 following values: 628 1 - an IP TML type with the protocol scheme as TCP+UDP, i.e., TCP 629 for control message transmission and UDP for redirect data 630 transmission. 631 2 - an IP TML type with the protocol scheme as TCP+DCCP, i.e., TCP 632 for control message transmission and DCCP for redirect data 633 transmission. 634 3 - an IP TML type with the protocol scheme as SCTP, i.e., SCTP for 635 both control and redirect data transmissions. 636 4 - an Ethernet TML type 637 5 � an ATM based TML type 639 The 'Working TML type' is assigned with a TML attribute id = 3. 641 4) TML media specific attributes 643 An individual TML specification may require PL to configure some 644 extra TML parameters specific to this TML media. If any, the TML 645 specification shall provide detailed definitions for such attributes. 647 5) Implementation specific TML attributes 649 An individual TML implementation may require PL to configure some 650 TML parameters specific to this implementation. If any, the 651 individual implementation will provide detailed definitions for such 652 attributes. 654 4.3. TML capabilities 656 TML capabilities represent TML abilities or capacities to provide 657 services to PL. A TML capability can only be read by PL via TML query 658 service primitive. 660 Note that, the TML query service primitive as described in Section 661 5.6 is used to query status of TML attributes as well as TML 662 capabilities. A TML attribute id or a TML capability id is 663 simultaneously used for the query operation. As a result, TML 664 attribute id and TML capability id should be kept harmonious and 665 unique to each other. 667 1) Supported TML type 669 PL may be interested to know what TML transportation type(s) the 670 associated TML can support. A TML implementation may be capable of 671 only one TML transport type or simultaneously several TML transport 672 types. This TML capability indicates the relative information to PL. 674 Note that, as mentioned before, in many cases, PL does not have to 675 manage TML types. TML may more rely on its own management tool or the 676 CE/FE managers for TML type management. As a result, this capability 677 is defined as an optional TML property, i.e., it is allowed some TML 678 implementations may decide not to provide this information to PL. 680 Whereas, if the capability is provided, it should include the 681 following information: 683 o a list of supported TML Type id(s) 684 the TML Type id is as defined before. 685 o configurable indicator 686 a flag to indicate if the TML is configurable or not for its 687 working type, i.e., if PL can use a working TML type attribute to set 688 the type to the TML. 690 The 'Supported TML type' capability is assigned with a TML 691 capability id = 10. 693 5. TML Service Primitives 695 5.1.Design Principles 697 The following principles are applied to the PL-TML service 698 primitives design: 700 1.PL-TML service primitives should hide implementation details 701 regarding reliability, security, multicast, congestion control, etc 702 from PL. 704 2.PL-TML service primitives should be decoupled from possible 705 changes of ForCES PL layer such as the update of ForCES protocol and 706 ForCES FE model. More specifically, primitives should be avoided to 707 be coupled with ForCES protocol PDU format. 709 5.2. TML Open 711 Format: 712 Result = TMLopen( ) 714 Result: 715 the returned result; it shall indicate whether the TML open is 716 succeeded or not. Moreover, if not succeeded, an id called 'TML id' 717 and used to identify the TML should be returned by the primitive. If 718 not succeeded, an error code may be returned to indicate the error 719 type. 721 Parameters: 722 none 724 Service Description: 725 The primitive is for PL to indicate a TML that the PL is going to 726 associate itself with the TML for services and hence the TML should 727 be ready for use. It highly depends upon each TML specification or 728 individual implementations on what a TML should do when it receives 729 this primitive. For some TMLs, this primitive may just act as an 730 indicator that the PL and the TML has been associated, while every 731 thing for providing services has already been there in the TML. For 732 other TMLs, when received the primitive, they may have to do 733 something to make it ready. For example, for a TML that adopts a 734 connectionless path as one of its transmission path, the path may 735 always be ready for message transportation without any extra setup; 736 while for a connection-oriented TML path, a TML open or a TML close 737 (see below) primitive may act as an indicator for the TML path to be 738 set or reset. However, it is also possible that some TML 739 specifications or implementations may choose to have such connection- 740 oriented path always ready for use when the TML has been initially 741 booted. 743 The 'TML id' returned by this primitive is as an identifier for the 744 PL to recognize the TML. Other primitives as described below will use 745 this id to identify a TML for operations. Having defined the TML id, 746 we imply that the usage scenario as one PL being associated with more 747 than one TML will not excluded by any TML specifications, and may be 748 applied in actual implementations. 750 An important note is, to better synchronize the operations between 751 peering PLs, if a TML has, for any reason, received any PL messages 752 from peering PL before local PL has formally opened the TML, the TML 753 shall discard all these messages. 755 5.3. TML close 757 Format: 758 Result = TMLclose( 759 TML id 760 ) 762 Result: 763 the returned result; it shall indicate whether the TML close 764 operation is succeeded or not. Moreover, if succeeded, an error code 765 may be returned to indicate the error type for the failed TML close. 767 Parameters: 768 o TML id (input) 769 the id of the TML to be closed. 771 Service Description: 772 By this primitive, a PL tears down its association with a TML. It 773 highly depends upon each TML specification or implementation on what 774 a TML should do when received this primitive. For some TMLs, this 775 primitive may just act as an indication that the association of the 776 PL and the TML is terminated and nothing more need to be done. For 777 other TMLs, when received the primitive, they may have to manage to 778 make it terminate the association, e.g., by disconnecting a 779 connection with peering TML. However, it is out of scope of this 780 document to have more details specified. 782 An important note is, to better synchronize the operations between 783 peer PLs, if a TML has, for any reason, received any PL messages from 784 peer PL after local PL has formally closed the TML, the TML shall 785 discard all these messages. 787 5.4.TML Configuration 789 Format: 790 Result = TMLconfig( 791 TML id, 792 operation type, 793 TML attribute id, 794 TML attribute data 795 [,optional parameters] 796 ) 798 Result: 799 the returned result; it shall indicate whether the TML configuration 800 is succeeded or not. Moreover, if not succeeded, an error code may be 801 returned to indicate the error type for the failed configuration. 803 Parameters: 804 o TML id (input) 805 the id of the TML to be configured. 806 o operation type (input) 807 As an input parameter, it specifies the operation type the TML 808 configuration primitive will do. The following operations must be 809 included: 810 SET � to set data to an attribute in the TML 811 DELETE � to delete data from an attribute in the TML or to 812 totally remove the attribute from the TML. 813 The following operation may be included: 814 MODIFY � to modify data for an attribute in the TML 816 Individual TMLs or implementations may define other operations if 817 necessary. 819 o TML attribute id (input) 820 the id inputted to TML; it uniquely specifies the TML attribute 821 the primitive is going to operate on. The id is assigned by 822 individual TML attribute definitions. 824 o TML attribute data (input) 825 a data unit that contains data elements to be configured to a TML 826 attribute. Actual data structure of the data unit will be defined by 827 individual TML implementations. 829 o optional parameters (input or output): 830 Individual TMLs or implementations may allow more parameters for 831 the TML attribute configuration. For e.g., some implementations may 832 choose to take an extra timeout parameter to make the primitive as a 833 non-blocking primitive call. This document does not exclude such 834 usages. 836 Service Description: 837 This primitive is used by PL to configure attributes of TML 838 according to service requirements made to the TML. TML attributes are 839 basically described as in Section 4.2. Every attribute to be operated 840 is identified by the TML attribute id. The TML attribute data 841 parameter provides necessary data for the operation. It is up to 842 individual TML implementations to specify data structure for the 843 attribute. It may be organized as an atomic data element or a 844 compound data element. Individual TML implementations should provide 845 detailed description on the data structure used for individual TML 846 attributes. 848 SET or DELETE operations are two basic operation types to a TML 849 attribute operation. In some cases, more operation types may be 850 required so that management to TML attributes may become more 851 portable to users. This is especially useful for management of TML 852 attributes like TML multicast lists. When PL configures multicast 853 lists to TML, it may require some form of operation variations 854 besides general operations as setting a new multicast list or 855 deleting an existing multicast list. For instance, PL may be 856 interested to add a member to, or delete a member from, an existing 857 multicast list. There may be two approaches for each TML 858 implementation to realize this. One is to define more types of 859 operations. The other is to specifically associate attribute data 860 structure definitions with operation types. Below is an example to 861 show that this is feasible: 863 o operation = SET, data = {multicast id, member1, member2, ...} 864 If the multicast list with the multicast id does not exist in 865 the TML, it is to set a new multicast list, or else, to add the new 866 members as listed to the existing multicast list. 868 o operation = DELETE, data = {multicast id } 869 to delete the whole multicast list with the multicast id. 871 o operation = DELETE, data = {multicast id, member1, member2, ...} 872 to delete the members as listed from an existing multicast list, 873 while keeping the multicast list id. 875 Note that the TML configuration service primitive is not designed to 876 return any attribute status after configured. To check the TML 877 attribute status, a TML query primitive as defined below should be 878 specifically used. 880 5.5. TML Query 882 Format: 883 Result = TMLquery( 884 TML id, 885 TML attribute id or TML capability id, 887 [,optional parameters] 888 ) 890 Result: 891 The result includes a returned result and a queried result; 893 The returned result shall indicate whether the primitive operation is 894 succeeded or not. Moreover, if not succeeded, an error code may be 895 returned to indicate the error type for the failed query operation. 897 The queried result shall include the queried data if the query 898 operation is succeeded. Each TML implementation shall define the data 899 structure for the queried result data. Each TML attribute or TML 900 capability may all have its specific data structure. 902 Note that it is not specified and restricted how the queried result 903 should be implemented in reality. Any techniques may be applied for 904 this purpose under condition that the queried data can be transferred 905 back to PL layer. For instance, some implementations may adopt a 906 return of function call for transferring the queried result data, 907 while some others may just adopt a parameter of function call for the 908 transferring. 910 Parameters: 911 o TML id (input) 912 the id of the TML to be operated. 914 o TML attribute id or TML capability id (input) 915 the id that uniquely specifies the TML attribute or TML capability 916 the primitive is going to query. 918 o optional parameters (input or output): 919 Besides the mandatory parameters as presented, individual TMLs or 920 implementations may adopt more parameters to customize the query 921 operation. For instance, it may be interested to query a multicast 922 list with a specified multicast id, rather than to query the whole 923 existing multicast lists. This may be realized by defining a 924 parameter composed of a multicast id as an index for the query. The 925 primitive may also include a timeout parameter to make the primitive 926 as a non-blocking operation. This document does not exclude such 927 usages. 929 Service Description: 930 This primitive is used by PL to query TML attributes or TML 931 capabilities to know their current status. The TML attribute id or 932 TML capability id is used to specify which attribute the primitive is 933 interested to query. Queried data are included in result of the 934 primitive execution. Note that this primitive definition does not 935 specify any technology on how the queried data shall be transferred 936 from TML to PL, so as to make the primitive definition independent of 937 any specific OS environments or implementation techniques. 939 5.6. TML send 941 Format: 942 Result = TMLsend( 943 TML id, 944 message destination id, 945 message type, 946 message priority, 947 message length, 948 message PDU 949 [, timeout] 950 [, more optional parameters] 951 ) 953 Result: 954 a returned code indicating if the TML send primitive is successful 955 or failed. If successful, a success code is returned. If failed, an 956 error code indicating the failure type is returned. 958 Parameters: 959 o TML id (input) 960 the id of the TML to be operated. 962 o message destination id (input) 963 the id indicating the destination of the ForCES PL message to be 964 sent; equal to the destination ID in the protocol message header. 966 o message type (input) 967 the type of the ForCES protocol message to be sent; equal to the 968 message type in the protocol message header. 970 o message priority (input) 971 the message priority of the protocol message to be sent; equal to 972 the priority bits in the protocol message header. 974 o message length (input) 975 the ForCES protocol message length to be sent, equal to the 976 message length field in the protocol message header, representing the 977 whole protocol message length in DWORDS ( 4 bytes) units. 979 o message PDU (input) 980 Protocol Data Unit for the whole ForCES protocol message, 981 including the message header and the body. Individual implementations 982 may need to further specify the endian way (big-endian or little- 983 endian, etc). 985 o timeout (input, optional parameter) 986 This is an optional parameter to optionally specify the primitive 987 as a non-blocking primitive call. The timeout value specifies how 988 long it may wait before abortion of the primitive call. If not 989 adopted, the primitive is executed in a blocking way. 991 o other optional parameters 992 Individual TMLs or implementations may specify more optional 993 parameters if necessary. 995 Service description: 996 By this service, PL tries to send a message to one (unicast) or more 997 (multicast) peer PLs via the TML. Note that this primitive has 998 explicitly included all information that are necessary for TML to 999 manage transmission of the PL message, therefore, there is no need 1000 for the TML to further retrieve more information by reading the PL 1001 message body PDU. In this way, it may be decoupled of changes in 1002 ForCES protocol PDU (e.g., by the protocol update) from TML services. 1004 The message destination id is used by the TML to map to TML layer 1005 transport addresses for the message transmission. This also includes 1006 the mapping of PL layer multicast ids to TML layer multicast 1007 addresses. Each TML specification should define the way for such 1008 mapping. 1010 The message type is used for the TML to infer the requirements from 1011 PL level for the message transmission, regarding its reliability, 1012 timeliness, security, and congestion control. With this message type, 1013 it is easy to recognize PL redirect messages from PL control messages. 1014 Individual TML specifications shall define how the message types are 1015 mapped to their individual transportation resources. 1017 The message priority is used for the TML to meet the PL requirement 1018 for the message transmission priority; it may also be used for TML to 1019 meet the requirements for reliability, timeliness, security, and 1020 congestion control. Individual TML specifications may define how the 1021 priority is mapped to their available transport mechanisms for 1022 prioritized timely transmission. Individual TML specifications may 1023 also define how the priority is used for other TML requirements. 1025 By use of an optional timeout parameter, the primitive may be 1026 applied either in a blocking way or a non-blocking way. 1028 5.7. TML receive 1030 Format: 1031 Result = TMLreceive( 1032 TML id, 1033 message length, 1034 message PDU, 1035 timeout, 1037 [, optional parameters] 1038 ) 1040 Result: 1041 a returned code indicating if the TML receive primitive is 1042 successful or failed. If successful, a success code is returned. If 1043 failed, an error code indicating the failure type is returned. 1045 Parameters: 1046 o TML id (input) 1047 the id of the TML to be operated. 1049 o message length (output) 1050 the length of the received ForCES protocol message, representing 1051 the whole protocol message length in DWORDS ( 4 bytes) units. It is a 1052 parameter output to PL by TML via this primitive. 1054 o message PDU (output) 1055 Protocol Data Unit for the whole ForCES protocol message received, 1056 including the message header and the bogy. Individual implementations 1057 may need to specify the endian way (big-endian or little-endian, etc). 1058 It is a parameter output to PL by TML via this primitive. 1060 o timeout (input) 1061 This is a mandatory parameter for the TML receive primitive. It 1062 mandates that the primitive shall work in a non-blocking way. The 1063 timeout value specifies how long it will mostly wait before abortion 1064 of this time receiving process. 1066 o optional parameters (input or output) 1067 Individual TMLs or implementations may specify more optional 1068 parameters for the primitive if necessary. 1070 Service description: 1071 This service is used for PL to synchronously receive ForCES protocol 1072 messages from peering TML via local TML. A received protocol message 1073 is returned via the parameters. The primitive specifies that it 1074 should be implemented in a non-blocking way. It is because that 1075 usually such receiving process may take high priority resources and a 1076 blocking way may make the system risk more of fatal errors. 1078 Note that a message arrive event as described before can also be 1079 used for PL to receive PL messages from TML. The difference is that 1080 this TML receive primitive makes PL to synchronously receive messages, 1081 while a message arrive event works in an asynchronous way receiving a 1082 message. Usually, an asynchronous method exploits more efficiency in 1083 terms of CPU resources. 1085 6. Operation Notes 1086 1) multicast 1088 In a ForCES architecture, PL level multicast may be most commonly 1089 for a CE to multicast a ForCES protocol message to multiple FEs. 1090 Operation steps for the ForCES system to setup this type of multicast 1091 may be presented as below: 1093 a. Before a PL level multicast could be established, usually a PL 1094 level unicast mechanism should first be established in the ForCES 1095 network element. This means a ForCES message should be able to be 1096 delivered in a unicast way between CE and FEs before we setup a 1097 multicast path. 1099 b. The CE PL (or its application layer) forms a PL level multicast 1100 list as defined in 2) of Section 4.2. Note that, because it 1101 represents multicast of a CE to FEs, the multicast list shall include 1102 a multicast id, the CE id, and a number of member FE ids. 1104 c. The multicast list should be sent to the CE TML by TML 1105 configuration service primitive as described by this document. When 1106 CE TML receives this multicast list, the TML is responsible to map 1107 the multicast list to its TML multicast mechanism. 1109 d. The multicast list may also need to be sent to all FE members of 1110 the multicast by use of ForCES protocol configure messages in order 1111 for the FEs to know they belong to this multicast group. Note that a 1112 multicast list has been defined in FE as an attribute of the FE 1113 Protocol LFB [ForCES-PL]. The FEs further send the PL multicast list 1114 to their FE TMLs by means of TML configuration primitive. When the 1115 FEs TMLs receive this multicast list, each TML is responsible to map 1116 the multicast list to its TML multicast mechanism. 1118 e. When a CE PL generates a message with the multicast id as its 1119 destination id and sends it to CE TML, the CE TML will use its TML 1120 level multicast mechanism to distribute the messages to individual 1121 FEs in the multicast group. 1123 f. At the FEs side, when a CE PL message with the multicast id 1124 arrives at the FEs TMLs, each TML use its TML multicast mechanism to 1125 accept the message, and further deliver it to the FE PL. 1127 Above steps may vary in some way according to different TML types 1128 with their different mechanism supporting for TML level multicast. 1130 2) TBD 1132 7. Security Considerations 1133 The risk of being DoS attacked by redirect data has already been 1134 addressed by RFC 3654, RFC 3746, the ForCES protocol specification 1135 [ForCES-PL], etc. Prevention of the DoS attack is one of the key 1136 points to secure the ForCES system. This document specified a TML 1137 event notification of alert from redirect DoS attack to specifically 1138 support a ForCES system to prevent such attack. 1140 TML congestion problem is a broader point of view that may affect 1141 performance of a ForCES system greatly. A TML event notification of 1142 TML congestion alert is defined for TML by this document, so that TML 1143 primitives defined by this document is more capable of improvement of 1144 ForCES system performance. 1146 This document does not define any mechanisms for security services 1147 like endpoint authentication of FE and CE, message authentication, 1148 and confidentiality service This document just reaffirms the 1149 requirement for this security service. This is because that this kind 1150 of security requirement are all specific to TML specifications of 1151 different TML media or individual implementations. Each TML 1152 specification shall provide detailed description on how to meet this 1153 requirement. 1155 8. Acknowledgements 1156 The authors would like to thank Joel M. Halpern, Huaiyuan Ma, et al 1157 for their invaluable comments during evolution of the document. 1159 9. References 1161 [RFC3654] H. Khosravi, et al., Requirements for Separation of IP 1162 Control and Forwarding, RFC 3654, November 2003. 1164 [RFC3746] L. Yang, et al., Forwarding and Control Element Separation 1165 (ForCES) Framework, RFC 3746, April 2004. 1167 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- 1168 ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006. 1170 [ForCES-Model] J. Halpern, E. Deleganes, ForCES Forwarding Element 1171 Model, draft-ietf-forces-model-06.txt. work-in-progress, Oct. 2006. 1173 10. Author's Address 1175 Weiming Wang 1176 Zhejiang Gongshang University 1177 149 Jiaogong Road 1178 Hangzhou 310035 1179 P.R.China 1180 Phone: +86-571-28877721 1181 EMail: wmwang@mail.zjgsu.edu.cn 1183 Jamal Hadi Salim 1184 Znyx Networks 1185 195 Stafford Rd. West 1186 Ottawa, Ontario 1187 Canada 1188 Phone: 1189 Email: hadi@znyx.com 1191 Alex Audu 1192 Garland SoftWorx 1193 Garland, Texas 1194 USA 1196 Phone: 1197 Email: alex.audu@garlandnetworx.com 1199 Copyright Statement 1201 Copyright (C) The IETF Trust (2007). 1203 This document is subject to the rights, licenses and restrictions 1204 contained in BCP 78, and except as set forth therein, the authors 1205 retain all their rights. 1207 This document and the information contained herein are provided on 1208 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1209 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1210 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 1211 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1212 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1213 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1214 OR FITNESS FOR A PARTICULAR PURPOSE.