idnits 2.17.1 draft-ietf-rohc-terminology-and-examples-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. 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 (February 13, 2003) is 7742 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-E. Jonsson 3 INTERNET-DRAFT Ericsson 4 Expires: August 2003 February 13, 2003 6 RObust Header Compression (ROHC): 7 Terminology and Channel Mapping Examples 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is a submission of the IETF ROHC WG. Comments should be 31 directed to the ROHC WG mailing list, rohc@ietf.org. 33 Abstract 35 RFC 3095 defines a Proposed Standard framework with profiles for 36 RObust Header Compression (ROHC). The standard introduces various 37 concepts which might be difficult to understand and especially to 38 relate correctly to the surrounding environments where header 39 compression may be used. This document aims at clarifying these 40 aspects of ROHC, discussing terms such as ROHC instances, ROHC 41 channels, ROHC feedback, and ROHC contexts, and how these terms 42 relate to other terms like network elements and IP interfaces, 43 commonly used for example when addressing MIB issues. 45 Table of Contents 47 1. Introduction..................................................2 48 2. Terminology...................................................3 49 3. ROHC External Terminology.....................................6 50 3.1. Network Elements and IP Interfaces.....................6 51 3.2. Channels...............................................6 52 3.3. A Unidirectional Point-to-Point Link Example...........8 53 3.4. A Bi-directional Point-to-Point Link Example...........8 54 3.5. A Bi-directional Multipoint Link Example...............9 55 3.6. A Multi-Channel Point-to-Point Link Example............9 56 4. ROHC Instances...............................................10 57 4.1. ROHC Compressors......................................11 58 4.2. ROHC Decompressors....................................12 59 5. ROHC Channels................................................12 60 6. ROHC Feedback Channels.......................................13 61 6.1. Single-Channel Dedicated ROHC FB Channel Example......14 62 6.2. Piggybacked/Interspersed ROHC FB Channel Example......15 63 6.3. Dual-Channel Dedicated ROHC FB Channel Example........16 64 7. ROHC Contexts................................................17 65 8. Summary......................................................17 66 9. Implementation Implications..................................18 67 10. Security Considerations.....................................19 68 11. Acknowledgements............................................19 69 12. References..................................................19 70 13. Author's Address............................................19 72 1. Introduction 74 In RFC 3095, the RObust Header Compression (ROHC) standard framework 75 is defined along with 4 compression profiles [RFC-3095]. Various 76 concepts are introduced within the standard, which might not all be 77 very extensively defined and described, and that can easily be an 78 obstacle when trying to understand the standard. This can be the case 79 especially when one considers how the various parts of ROHC relate to 80 the surrounding environments where header compression may be used. 82 The purpose of this document is to clarify these aspects of ROHC 83 through examples and additional terminology, discussing terms such as 84 ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts. This 85 especially means to clarify how these terms relate to other terms, 86 such as network elements and IP interfaces, which are commonly used 87 for example when addressing MIB issues. One explicit goal with this 88 document is to support and simplify the ROHC MIB development work. 90 The main part of this document, sections 3 to 8, focuses on 91 clarifying the conceptual aspects, entity relationships, and 92 terminology of ROHC [RFC-3095]. After that, section 9 explains some 93 implementation implications that arise from these conceptual aspects. 95 2. Terminology 97 ROHC instance 99 A logical entity that performs header compression or decompression 100 according to one or several ROHC profiles can be referred to as a 101 ROHC instance. A ROHC instance is either a ROHC compressor 102 instance or a ROHC decompressor instance. See section 4. 104 ROHC compressor instance 106 A ROHC compressor instance is a logical entity that performs 107 header compression according to one or several ROHC profiles. 108 There is a one-to-one relation between a ROHC compressor instance 109 and a ROHC channel, where the ROHC compressor is located at the 110 input end of the ROHC channel. See section 4.1. 112 ROHC decompressor instance 114 A ROHC decompressor instance is a logical entity that performs 115 header decompression according to one or several ROHC profiles. 116 There is a one-to-one relation between a ROHC decompressor 117 instance and a ROHC channel, where the ROHC decompressor is 118 located at the output end of the ROHC channel. See section 4.2. 120 Corresponding decompressor 122 When talking about a compressor's corresponding decompressor, this 123 refers to the peer decompressor located at the other end of the 124 ROHC channel to which the compressor sends compressed header 125 packets, i.e. the decompressor that decompresses the headers 126 compressed by the compressor. 128 Corresponding compressor 130 When talking about a decompressor's corresponding compressor, this 131 refers to the peer compressor located at the other end of the ROHC 132 channel from which the decompressor receives compressed header 133 packets, i.e. the compressor that compresses the headers the 134 decompressor decompresses. 136 ROHC peers 138 A ROHC compressor and its corresponding ROHC decompressor are 139 referred to as ROHC peers. 141 Link 143 A communication path between two network entities is in this 144 document generally referred to as a link. 146 Bi-directional compression 148 If there are means to send feedback information from a 149 decompressor to its corresponding compressor, the compression 150 performance can be improved. This way of operating, utilizing 151 the feedback possibility for improved compression performance, 152 is referred to as bi-directional compression. 154 Unidirectional compression 156 If there are no means to send feedback information from a 157 decompressor to its corresponding compressor, the compression 158 performance might not be as good as if feedback can be 159 utilized. This way of operating, without making use of feedback 160 for improved compression performance, is referred to as 161 unidirectional compression. 163 ROHC channel 165 When a ROHC compressor has transformed original packets into ROHC 166 packets with compressed headers, these ROHC packets are sent to 167 the corresponding decompressor through a logical point-to-point 168 connection dedicated to that traffic. Such a logical channel, 169 which only has to carry data in this single direction from 170 compressor to decompressor, is referred to as a ROHC channel. 171 See further section 5. 173 ROHC feedback channel 175 To allow bi-directional compression operation, a logical 176 point-to-point connection must be provided for feedback data from 177 the decompressor to its corresponding compressor. Such a logical 178 channel, which only has to carry data in the single direction from 179 decompressor to compressor, is referred to as a ROHC feedback 180 channel. See further section 6. 182 Co-located compressor/decompressor 184 A minimal ROHC instance is only a compressor or a decompressor, 185 communicating with a corresponding decompressor or compressor peer 186 at the other end of a ROHC channel, thus handling packet streams 187 sent in one direction over the link. However, in many cases the 188 link will carry packet streams in both directions, and it would 189 then be desirable to also perform header compression in both 190 directions. That would require both a ROHC compressor and a ROHC 191 decompressor at each end of the link, each referred to as a 192 co-located compressor/decompressor pair. 194 Associated compressor/decompressor 196 If there is a co-located ROHC compressor/decompressor pair at each 197 end of a link, feedback messages can be transmitted from 198 a ROHC decompressor to its corresponding compressor by creating a 199 virtual ROHC feedback channel among the compressed header packets 200 sent from the co-located ROHC compressor to the decompressor 201 co-located with the compressor at the other end. When a co-located 202 ROHC compressor/decompressor pair is connected for this purpose, 203 they are said to be associated with each other. 205 Interspersed feedback 207 Feedback from a ROHC decompressor to a ROHC compressor can either 208 be sent on a separate ROHC feedback channel dedicated to feedback 209 packets, or sent among compressed header packets going in the 210 opposite direction from a co-located (associated) compressor to a 211 similarly co-located decompressor at the other end of the link. 212 If feedback packets are transmitted in the latter way and sent as 213 stand-alone packets, this is referred to as interspersed feedback. 214 See further section 6.2 for an example. 216 Piggybacked feedback 218 Feedback from a ROHC decompressor to a ROHC compressor can either 219 be sent on a separate ROHC feedback channel dedicated to feedback 220 packets, or sent among compressed header packets going in the 221 opposite direction from a co-located (associated) compressor to a 222 similarly co-located decompressor at the other end of the link. 223 If feedback packets are transmitted in the latter way and sent 224 encapsulated within compressed header packets going in the other 225 direction, this is referred to as piggybacked feedback. 226 See further section 6.2 for an example. 228 Dedicated feedback channel 230 A dedicated feedback channel is a logical layer two channel from 231 a ROHC decompressor to a ROHC compressor, used only to transmit 232 feedback packets. See further section 6.1 and 6.3 for examples. 234 3. ROHC External Terminology 236 When considering aspects of ROHC that relate to the surrounding 237 networking environment where header compression may be applied, 238 unnecessary confusion is easily created because a common, well 239 understood and well defined, terminology is missing. One major goal 240 with this document is to define the preferred terminology to use when 241 discussing header compression network integration issues. 243 3.1. Network Elements and IP Interfaces 245 Header compression is applied over certain links, between two 246 communicating entities in a network. Such entities may be referred to 247 as "nodes", "network devices", or "network elements", all terms 248 usually having the same meaning. However, practice within the area of 249 network management favors using the term "network element", which is 250 therefore consistently used throughout the rest of this document. 252 A network element communicates through one or several network 253 interfaces, which are often subject to network management, as defined 254 by MIB specifications. In all IP internetworking, each such interface 255 has its own IP identity, providing a common network interface 256 abstraction, independent of the link technology hidden below the 257 interface. Throughout the rest of this document, such interfaces will 258 be referred to as "IP interfaces". 260 To visualize the above terms, the top level hierarchy of a network 261 element is thus the following, with one or several IP interfaces: 263 +-----------------------------------------------------+ 264 | Network Element | 265 +---------------+--+---------------+------------------+ 266 | IP | | IP | 267 | Interface | | Interface | 268 +---------------+ +---------------+ ... 270 The next section further builds on this top level hierarchy by 271 looking at what is below an IP interface. 273 3.2. Channels 275 As mentioned in the previous section, an IP interface can be 276 implemented on top of almost any link technology, although different 277 link technologies have different characteristics, and provide 278 communication by different means. However, all link technologies 279 provide the common capability to send and/or receive data to/from the 280 IP interface. A generic way of visualizing the common ability to 281 communicate is to envision it as one or several logical communication 282 channels provided by the link, where each channel can be either bi- 283 directional or unidirectional. Such logical point-to-point 284 connections will throughout the rest of this document be referred to 285 as "channels", either bi-directional or unidirectional. Note that 286 this definition of "channels" is less restrictive than the definition 287 of "ROHC channels", as given in section 5. 289 Extending the above network element hierarchy with the concept of 290 channels would then lead to the following: 292 +-----------------------------------------------------+ 293 | Network Element | 294 +---------------+--+---------------+------------------+ 295 | IP | | IP | 296 | Interface | | Interface | 297 ++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ... 298 |C| |C| |C| |C| |C| |C| 299 |h| |h| |h| |h| |h| |h| 300 |a| |a| |a| |a| |a| |a| 301 |n| |n| |n| ... |n| |n| |n| ... 302 |n| |n| |n| |n| |n| |n| 303 |e| |e| |e| |e| |e| |e| 304 |l| |l| |l| |l| |l| |l| 305 : : : : : : : : : : : : 307 Whether there is more than one channel, and whether the channel(s) 308 is/are bi-directional or unidirectional (or a mix of both) is link 309 technology dependent, as is the way in which channels are logically 310 created. 312 The following subsections, 3.3-3.6, give a number of different link 313 examples, and relate these to the general descriptions above. 314 Further, each section discusses how header compression might be 315 applied in that particular case. The core questions for header 316 compression are: 317 - Are channels bi- or unidirectional? 318 - Is the link point-to-point? If not, a lower layer addressing 319 scheme is needed to create logical point-to-point channels. 321 Note that these subsections talk about header compression in general, 322 while later sections will address the case of ROHC in more detail. 323 Further, one should remember that in the later sections, the general 324 channel definition is slightly enhanced for header compression by the 325 definition of the ROHC channel (section 5) and the ROHC feedback 326 channel (section 6), while here the basic channel concept is used, as 327 defined above. 329 3.3. A Unidirectional Point-to-Point Link Example 331 The simplest possible link example one can derive from the general 332 overview above is the case with one single unidirectional channel 333 between two communicating network elements. 335 +-----------------+ +-----------------+ 336 | Network Element | | Network Element | 337 +-----------------+ +-----------------+ 338 | IP | | IP | 339 | Interface | | Interface | 340 +------+ +------+ +------+ +------+ 341 | | | | 342 | +--------------------------------+ | 343 | -> Unidirectional channel -> | 344 +----------------------------------------+ 346 A typical example of a point-to-point link with one unidirectional 347 channel like this is a satellite link. Since there is no return path 348 present, only unidirectional header compression can be applied here. 350 3.4. A Bi-directional Point-to-Point Link Example 352 Taking the above example one step further, the natural extension 353 would be an example with one single bi-directional channel between 354 two communicating network elements. In this example, there are still 355 only two endpoints and one single channel, but the channel is simply 356 enhanced to allow bi-directional communication. 358 +-----------------+ +-----------------+ 359 | Network Element | | Network Element | 360 +-----------------+ +-----------------+ 361 | IP | | IP | 362 | Interface | | Interface | 363 +------+ +------+ +------+ +------+ 364 | | | | 365 | +--------------------------------+ | 366 | <-> Bi-directional channel <-> | 367 +----------------------------------------+ 369 A typical example of a point-to-point link with such a bi-directional 370 channel is a PPP modem connection over a regular telephone line. 371 Header compression can easily be applied here as well, as is usually 372 done over e.g. PPP, and the compression scheme can make use of the 373 return path to improve compression performance. 375 3.5. A Bi-directional Multipoint Link Example 377 Leaving the simple point-to-point link examples, this section 378 addresses the case of a bi-directional link connecting more than two 379 communicating network elements. To simplify the example, the case 380 with three endpoints is considered. 382 +-----------------+ +-----------------+ +-----------------+ 383 | Network Element | | Network Element | | Network Element | 384 +-----------------+ +-----------------+ +-----------------+ 385 | IP | | IP | | IP | 386 | Interface | | Interface | | Interface | 387 +------+ +------+ +------+ +------+ +------+ +------+ 388 | | | | | | 389 | | | | | | 390 | +-----------------+ +-----------------+ | 391 | <-> Bi-directional "shared channel" <-> | 392 +-----------------------------------------------+ 394 A typical example of a multipoint link with such a bi-directional 395 "shared channel" is an Ethernet. Since the channel is shared, 396 applying header compression would require a lower layer addressing 397 scheme, to provide logical point-to-point channels, according to the 398 definition of "channels". 400 As an aside, it should be noted that a case of unidirectional 401 multipoint links is basically the same as a number of unidirectional 402 point-to-point links. In such a case, each receiver only sees one 403 single sender, and the sender's behavior is independent of the number 404 of receivers and unaffected by their behavior. 406 3.6. A Multi-Channel Point-to-Point Link Example 408 This final example addresses a scenario which is expected to be 409 typical in many environments where ROHC will be applied. The key 410 point of the example is the multi-channel property, which is common 411 in for example cellular environments. Data through the same IP 412 interface might here be transmitted on different channels, depending 413 on its characteristics. In the following example, there are three 414 channels present, one bi-directional, and one unidirectional in each 415 direction, but the channel configuration could of course be 416 arbitrary. 418 +-----------------+ +-----------------+ 419 | Network Element | | Network Element | 420 +-----------------+ +-----------------+ 421 | IP | | IP | 422 | Interface | | Interface | 423 +-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+ 424 | | | | | | | | | | | | 425 | | | | | +--------------------------+ | | | | | 426 | | | | | <- Unidirectional channel <- | | | | | 427 | | | | +------------------------------+ | | | | 428 | | | | | | | | 429 | | | | | | | | 430 | | | +--------------------------------------+ | | | 431 | | | <-> Bi-directional channel <-> | | | 432 | | +------------------------------------------+ | | 433 | | | | 434 | | | | 435 | +--------------------------------------------------+ | 436 | -> Unidirectional channel -> | 437 +------------------------------------------------------+ 439 As mentioned above, a typical example of a multi-channel link is a 440 cellular wireless link. In this example, header compression would be 441 applicable on a per-channel basis, for each channel operating either 442 in a bi-directional or unidirectional manner, depending on the 443 channel properties. 445 4. ROHC Instances 447 For various purposes, such as network management on an IP interface 448 implementing ROHC, it is necessary to identify the various ROHC 449 entities that might be present on an interface. Such a minimal ROHC 450 entity will from now on be referred to as a "ROHC instance". A ROHC 451 instance can be one of two different types, either a "ROHC 452 compressor" or a "ROHC decompressor" instance, and an IP interface 453 can have N ROHC compressors and M ROHC decompressors, where N and M 454 are arbitrary numbers. It should be noted that although a compressor 455 is often co-located with a decompressor, a ROHC instance can never 456 include both a compressor and a decompressor; where both are present, 457 they will be referred to as two ROHC instances. 459 The following two subsections describe the two kinds of ROHC 460 instances and their external interfaces, while sections 5 and 6 461 address how communication over these interfaces is realized through 462 "ROHC channels" and "ROHC feedback channels". Section 7 builds on top 463 of the instance, channel and feedback channel concepts and clarifies 464 how ROHC contexts map to this. 466 It should be noted that all figures in sections 4-6 have been rotated 467 90 degrees to simplify drawing, i.e. they do not show a "stack view". 469 4.1. ROHC Compressors 471 A ROHC compressor instance supports header compression according to 472 one or several ROHC profiles. Apart from potential configuration or 473 control interfaces, a compressor instance receives and sends data 474 through 3 inputs and 1 output, as illustrated by the figure below: 476 +--------------+ 477 -> UI -> | | -> CO -> 478 | ROHC | 479 | Compressor | 480 -> PI -> | | <- FI <- 481 +--------------+ 483 Uncompressed Input (UI): Uncompressed packets are delivered from 484 higher layers to the compressor through 485 the UI. 487 Compressed Output (CO): Compressed packets are sent from the 488 compressor through the CO, which is always 489 connected to the input end of a ROHC 490 channel (see section 5). 492 Feedback Input (FI): Feedback from the corresponding 493 [optional] decompressor is received by the compressor 494 through the FI, which (if present) is 495 connected to the output end of a ROHC 496 feedback channel of some kind (see section 497 6). When there are no means to transmit 498 feedback from decompressor to compressor, 499 FI is not used, and bi-directional 500 compression will not be possible. 502 Piggyback Input (PI): If the compressor is associated with a 503 [optional] co-located decompressor, for which the 504 compressor delivers feedback to the 505 other end of the link, feedback data 506 for piggybacking is delivered to the 507 compressor through the PI. If this input 508 is used, it is connected to the FO of the 509 co-located decompressor (see section 4.2). 511 4.2. ROHC Decompressors 513 A ROHC decompressor instance supports header decompression according 514 to one or several ROHC profiles. Apart from potential configuration 515 or control interfaces, a decompressor instance receives and sends 516 data through 1 input and 3 outputs, as illustrated by the figure 517 below: 518 +--------------+ 519 -> CI -> | | -> DO -> 520 | ROHC | 521 | Decompressor | 522 <- FO <- | | -> PO -> 523 +--------------+ 525 Compressed Input (CI): Compressed packets are received by the 526 decompressor through the CI, which is 527 always connected to the output end of a 528 ROHC channel (see section 5). 530 Decompressed Output (DO): Decompressed packets are delivered from 531 the decompressor to higher layers through 532 the DO. 534 Feedback Output (FO): Feedback to the corresponding compressor 535 [optional] is sent from the compressor through the 536 FO, which (if present) is connected to 537 the input end of a ROHC feedback channel 538 of some kind (see section 6). When there 539 are no means to transmit feedback from 540 decompressor to compressor, FO is not 541 used, and bi-directional compression will 542 not be possible. 544 Piggyback Output (PO): If the decompressor is associated with 545 [optional] a co-located compressor, to which the 546 decompressor delivers feedback it 547 receives piggybacked from the other end 548 of the link, the received feedback data 549 is delivered from the decompressor 550 through the PO. If this output is used, 551 it is connected to the FI of the co- 552 located compressor (see section 4.1). 554 5. ROHC Channels 556 In section 3, a general concept of channels was introduced. According 557 to that definition, a channel is basically a logical point-to-point 558 connection between the IP interfaces of two communicating network 559 elements. By that definition, a channel represents the kind of 560 logical connection needed to make header compression generally 561 applicable, and then the channel properties control whether 562 compression can operate in a unidirectional or bi-directional manner. 564 The channel concept thus facilitates general header compression 565 discussions, but since it groups unidirectional and bi-directional 566 connections together it does not provide the means for describing 567 details of how ROHC logically works. Therefore, for the case of ROHC, 568 the channel concept is enhanced and a more restricted concept of 569 "ROHC channels" is defined. 571 A ROHC channel has the same properties as a channel, with the 572 difference that a ROHC channel is always unidirectional. A ROHC 573 channel therefore has one single input endpoint, connected to the CO 574 of one single ROHC compressor instance, and one single output 575 endpoint, connected to the CI of one single ROHC decompressor 576 instance. A ROHC channel must thus in this way be logically dedicated 577 to one ROHC compressor and one ROHC decompressor, hereafter referred 578 to as ROHC peers, creating a one-to-one mapping between a ROHC 579 channel and two ROHC compressor/decompressor peers. 581 +--------------+ --->-->-->-->--- +--------------+ 582 | | -> CO -> ROHC Channel -> CI -> | | 583 | ROHC | --->-->-->-->--- | ROHC | 584 | Compressor | | Decompressor | 585 | | | | 586 +--------------+ +--------------+ 588 In many cases the lower layer channel is by nature bi-directional, 589 but for ROHC communication over that channel, a ROHC channel would 590 only represent one communication direction of that channel. For bi- 591 directional channels, a common case would be to logically allocate 592 one ROHC channel in each direction, allowing ROHC compression to be 593 performed in both directions. The reason for defining ROHC channels 594 as unidirectional is basically to separate and generalize the concept 595 of feedback, as described and exemplified in section 6. 597 6. ROHC Feedback Channels 599 Since ROHC can be implemented over various kinds of links, 600 unidirectional or bi-directional one-channel links as well as multi- 601 channel links, the logical transmission of feedback from decompressor 602 to compressor has been separated out from the transport of actual 603 ROHC packets through the definition of ROHC channels as always being 604 unidirectional from compressor to decompressor. This means that an 605 additional channel concept must be defined for feedback, which is 606 what will hereafter be referred to as "ROHC feedback channels". 608 In the same way as a ROHC channel is a logically dedicated 609 unidirectional channel from a ROHC compressor to its corresponding 610 ROHC peer decompressor, a ROHC feedback channel is a logically 611 dedicated unidirectional channel from a ROHC decompressor to its 612 corresponding ROHC peer compressor. A ROHC feedback channel thus has 613 one single input endpoint, connected to the FO of one single ROHC 614 decompressor instance, and one single output endpoint, connected to 615 the FI of one single ROHC compressor instance. 617 +--------------+ +--------------+ 618 | | | | 619 | ROHC | | ROHC | 620 | Compressor | --<--<--<--<--<-- | Decompressor | 621 | | <- FI <- ROHC FB Channel <- FO <- | | 622 +--------------+ --<--<--<--<--<-- +--------------+ 624 The reason for making this simplification and logically separate ROHC 625 channels from ROHC feedback channels is generality for handling of 626 feedback. ROHC has been designed with the assumption of logical 627 separation, which creates flexibility in realizing feedback 628 transport, as discussed in [RFC-3095, section 5.2.1]. There are no 629 restrictions on how to implement a ROHC feedback channel, other than 630 that it must be made available and be logically dedicated to the ROHC 631 peers, if bi-directional compression operation is to be allowed. 633 The following subsections provide some, not at all exhaustive, 634 examples of how a ROHC feedback channel might possibly be realized. 636 6.1. Single-Channel Dedicated ROHC Feedback Channel Example 638 This section illustrates a one-way compression example where one bi- 639 directional channel has been configured to represent a ROHC channel 640 in one direction and a dedicated ROHC feedback channel in the other 641 direction. 642 Bi-directional channel 643 .................. 644 +--------------+ : -->-->-->-->-- : +--------------+ 645 --> |UI CO| --> : ROHC Channel : --> |CI DO| --> 646 | ROHC | : -->-->-->-->-- : | ROHC | 647 | Compressor | : : | Decompressor | 648 | | : --<--<--<--<-- : | | 649 o |PI FI| <-- : FB Channel : <-- |FO PO| o 650 +--------------+ : --<--<--<--<-- : +--------------+ 651 :................: 653 In this example, feedback is sent on its own dedicated channel, as 654 discussed in e.g. feedback realization example 1-3 of ROHC [RFC-3095, 655 page 44]. This means that the piggybacking/interspersing mechanism of 656 ROHC is not used, and the PI/PO connections are thus left open 657 (marked with a "o"). To facilitate communication with ROHC 658 compression in a two-way manner using this approach, an identical 659 configuration must be provided for the other direction, i.e. making 660 use of four logical unidirectional channels. 662 6.2. Piggybacked/Interspersed ROHC Feedback Channel Example 664 This section illustrates how a bi-directional channel has been 665 configured to represent one ROHC channel in each direction, while 666 still allowing feedback to be transmitted through ROHC piggybacking 667 and interspersing. 669 Bi-directional channel 670 .................. 671 +--------------+ : -->-->-->-->-- : +--------------+ 672 --> |UI CO| --> : ROHC Channel A : --> |CI DO| --> 673 | ROHC | : -->-->-->-->-- : | ROHC | 674 | Compressor | : : | Decompressor | 675 | A | : : | A | 676 +-> |PI FI| <-+ : : +-- |PO FO| --+ 677 | +--------------+ | : : | +--------------+ | 678 | | : : | | 679 | | : : | | 680 | +--------------+ | : : | +--------------+ | 681 +-- |FO PO| --+ : : +-> |FI PI| <-+ 682 | ROHC | : : | ROHC | 683 | Decompressor | : : | Compressor | 684 | B | : --<--<--<--<-- : | B | 685 <-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <-- 686 +--------------+ : --<--<--<--<-- : +--------------+ 687 :................: 689 In this example, feedback is transmitted piggybacked or interspersed 690 among compressed header packets in the ROHC channels, as discussed in 691 e.g. feedback realization example 4-6 of ROHC [RFC-3095, page 44]. 692 Feedback from decompressor A to compressor A is here sent through 693 FO(A)->PI(B), piggybacked on a compressed packet over ROHC channel B, 694 and delivered to compressor A through PO(B)->FI(A). A logical ROHC 695 feedback channel is thus provided from the PI input at compressor B 696 to the PO output at decompressor B. It should be noted that in this 697 picture, PO and FO at the decompressors have been swapped to simplify 698 drawing. 700 6.3. Dual-Channel Dedicated ROHC Feedback Channel Example 702 This section illustrates how two bi-directional channels have been 703 configured to represent two ROHC channels and two dedicated ROHC 704 feedback channels, respectively. 706 Bi-directional channel 707 .................. 708 +--------------+ : -->-->-->-->-- : +--------------+ 709 ->|UI CO| --> : ROHC Channel A : --> |CI DO|-> 710 | ROHC | : -->-->-->-->-- : | ROHC | 711 | Compressor | : : | Decompressor | 712 | A | : : | A | 713 | | : : | | 714 +-> |FI PI| o : : o |PO FO| --+ 715 | +--------------+ : --<--<--<--<-- : +--------------+ | 716 | +- : ROHC Channel B :<-+ | 717 | | : --<--<--<--<-- : | | 718 | +--------------+ | :................: | +--------------+ | 719 | <-|DO CI|<-+ +- |CO UI|<- | 720 | | ROHC | | ROHC | | 721 | | Decompressor | Bi-directional channel | Compressor | | 722 | | B | .................. | B | | 723 | | | : -->-->-->-->-- : | | | 724 | o|PO FO| --> : FB Channel B : --> |FI PI|o | 725 | +--------------+ : -->-->-->-->-- : +--------------+ | 726 | : : | 727 | : --<--<--<--<-- : | 728 +----------------------- : FB Channel A : <----------------------+ 729 : --<--<--<--<-- : 730 :................: 732 In this example, feedback is in both directions sent on its own 733 dedicated channel, as discussed in e.g. feedback realization example 734 1-3 of ROHC [RFC-3095, page 44]. With this configuration, the 735 piggybacking/interspersing mechanism of ROHC is not used, and the 736 PI/PO connections are thus left open (marked with a "o"). It should 737 be noted that in this picture FI/PI and PO/FO at the A-instances have 738 been swapped to simplify drawing, while the B-instances have been 739 horizontally mirrored. 741 7. ROHC Contexts 743 In previous sections it has been clarified that one network element 744 may have multiple IP interfaces, one IP interfaces may have multiple 745 ROHC instances running (not necessarily both compressors and 746 decompressors), and for each ROHC instance there is exactly one ROHC 747 channel and optionally one ROHC feedback channel. How ROHC channels 748 and ROHC feedback channels are realized will differ from case to 749 case, depending on the actual layer two technology used. 751 Each compressor/decompressor can further compress/decompress an 752 arbitrary (but limited) number of concurrent packet streams sent over 753 the ROHC channel connected to that compressor/decompressor. Each 754 packet stream relates to one particular context in the 755 compressor/decompressor. When sent over the ROHC channel, compressed 756 packets are labeled with a context identifier (CID), indicating which 757 context the compressed packet corresponds to. There is thus a one-to- 758 one mapping between the number of contexts that can be present in a 759 compressor/decompressor and the context identifier (CID) space used 760 in compressed packets over that ROHC channel. This is illustrated by 761 the following figure: 763 +------------------------------------------------------------------+ 764 | IP Interface | 765 +---------------+----+---------------+----+---------------+--------+ 766 | ROHC | | ROHC | | ROHC | 767 | Compressor | | Compressor | | Decompressor | 768 | Context 0...N | | Context 0...M | | Context 0...K | ... 769 +--+---------+--+ +--+---------+--+ +--+---------+--+ 770 ^ | ^ | : ^ 771 : CID | : CID | : CID | 772 : 0...N | : 0...M | : 0...K | 773 : v : v v | 774 ROHC ROHC ROHC ROHC ROHC ROHC 775 Feedback Channel Feedback Channel Feedback Channel 776 Channel Channel Channel 778 It should be noted that each ROHC instance at an IP interface 779 therefore has its own context and CID space, and it must be ensured 780 that the CID size of the corresponding decompressor at the other end 781 of the ROHC channel is not smaller than the CID space of the 782 compressor. 784 8. Summary 786 This document has introduced and defined a number of concepts and 787 terms for use in ROHC network integration, and explained how the 788 various pieces relate to each other. In the following bullet list, 789 the most important relationship conclusions are repeated: 791 - A network element may have one or several IP interfaces. 793 - Each IP interface is connected to one or several logical layer 794 two channels. 796 - Each IP interface may have one or several ROHC instances, either 797 compressors, decompressors, or an arbitrary mix of both. 799 - For each ROHC instance, there is exactly one ROHC channel, and 800 optionally exactly one ROHC feedback channel. 802 - How ROHC channels and ROHC feedback channels are realized through 803 the available logical layer two channels will vary, and there 804 is therefore no general relation between ROHC instances and 805 logical layer two channels. ROHC instances map only to ROHC 806 channels and ROHC feedback channels. 808 - Each compressor owns its own context identifier (CID) space, 809 which is the multiplexing mechanism it uses when sending 810 compressed header packets to its corresponding decompressor. 811 That CID space thus defines how many compressed packet streams 812 can be concurrently sent over the ROHC channel allocated to the 813 compressor/decompressor peers. 815 9. Implementation Implications 817 This section will address how the conceptual aspects discussed above 818 affect implementations of ROHC. 820 ROHC is defined as a general header compression framework on top of 821 which compression profiles can be defined for each specific set of 822 headers to compress. Although the framework holds a number of 823 important mechanisms, the separation between framework and profiles 824 is mainly a separation from a standardization point of view, to 825 indicate what must be common to all profiles, what must be defined by 826 all profiles, and what is profile-specific details. To implement the 827 framework as a separate module is thus not an obvious choice, 828 especially if one wants to use profile implementations from different 829 vendors. However, optimized implementations will probably separate 830 the common parts and implement those in a ROHC framework module, and 831 add profile modules to that. 833 A ROHC instance might thus consist of various pieces of 834 implementation modules, profiles, and potentially also a common ROHC 835 module, possibly from different vendors. If vendor and implementation 836 version information is made available for network management 837 purposes, this should thus be done on a per-profile basis, and in 838 addition to that potentially also for the instance as a whole. 840 10. Security Considerations 842 This document is of an informative nature, and does not have any 843 security aspects to address. 845 11. Acknowledgements 847 Thanks to Juergen Quittek, Hans Hannu, Carsten Bormann, and Ghyslain 848 Pelletier for fruitful discussions, improvement suggestions, and 849 review. Thanks also to Peter Eriksson for doing a language review. 851 12. References 853 [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 854 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 855 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 856 K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust 857 Header Compression (ROHC)", RFC 3095, July 2001. 859 13. Author's Address 861 Lars-Erik Jonsson Tel: +46 920 20 21 07 862 Ericsson AB Fax: +46 920 20 20 99 863 Box 920 864 SE-971 28 Lulea 865 Sweden EMail: lars-erik.jonsson@ericsson.com 867 Full Copyright Statement 869 Copyright (C) The Internet Society (2003). All Rights Reserved. 871 This document and translations of it may be copied and furnished to 872 others, and derivative works that comment on or otherwise explain it 873 or assist in its implementation may be prepared, copied, published 874 and distributed, in whole or in part, without restriction of any 875 kind, provided that the above copyright notice and this paragraph are 876 included on all such copies and derivative works. However, this 877 document itself may not be modified in any way, such as by removing 878 the copyright notice or references to the Internet Society or other 879 Internet organizations, except as needed for the purpose of 880 developing Internet standards in which case the procedures for 881 copyrights defined in the Internet Standards process must be 882 followed, or as required to translate it into languages other than 883 English. 885 The limited permissions granted above are perpetual and will not be 886 revoked by the Internet Society or its successors or assigns. 888 This document and the information contained herein is provided on an 889 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 890 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 891 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 892 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 893 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 895 This Internet-Draft expires August 13, 2003.