idnits 2.17.1 draft-ietf-ipdvb-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1881. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 33) being 109 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 9. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6919 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MPEG2' is mentioned on line 149, but not defined == Missing Reference: 'ETSI-BSM' is mentioned on line 208, but not defined == Missing Reference: 'ETSI-DVB' is mentioned on line 253, but not defined == Missing Reference: 'ID-ipdvb-arch' is mentioned on line 384, but not defined == Missing Reference: 'DVB-RC' is mentioned on line 679, but not defined == Missing Reference: 'AR-DRAFT' is mentioned on line 716, but not defined == Missing Reference: 'ITU-AAL5' is mentioned on line 786, but not defined == Missing Reference: 'LLC' is mentioned on line 1923, but not defined == Missing Reference: 'RFCROHC' is mentioned on line 917, but not defined == Missing Reference: 'ND' is mentioned on line 1084, but not defined == Missing Reference: 'RFC 3376' is mentioned on line 1376, but not defined == Missing Reference: 'RFC3569' is mentioned on line 1387, but not defined == Missing Reference: 'SI-DAT' is mentioned on line 1930, but not defined == Missing Reference: 'DVB-SIDAT-368' is mentioned on line 1948, but not defined == Unused Reference: 'ATSC-DATG' is defined on line 1665, but no explicit reference was found in the text == Unused Reference: 'ATSC-G' is defined on line 1673, but no explicit reference was found in the text == Unused Reference: 'ATSC-PSIP-TC' is defined on line 1677, but no explicit reference was found in the text == Unused Reference: 'ATSC-S' is defined on line 1681, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBC' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS' is defined on line 1702, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBS2' is defined on line 1706, but no explicit reference was found in the text == Unused Reference: 'ETSI-DVBT' is defined on line 1711, but no explicit reference was found in the text == Unused Reference: 'ETSI-IPDC' is defined on line 1720, but no explicit reference was found in the text == Unused Reference: 'ID-IPDVB-AR' is defined on line 1728, but no explicit reference was found in the text == Unused Reference: 'Ken87' is defined on line 1753, but no explicit reference was found in the text == Unused Reference: 'OPEN-CABLE' is defined on line 1757, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 1761, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 1767, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 1770, but no explicit reference was found in the text == Unused Reference: 'RFC2507' is defined on line 1782, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 1789, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 1802, but no explicit reference was found in the text -- No information found for draft-ipdvb-ule - is the name correct? == Outdated reference: A later version (-04) exists of draft-fair-ipdvb-ar-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 7 errors (**), 0 flaws (~~), 36 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M.J. Montpetit ed. 2 Internet Draft MJMontpetit.com 3 Document: draft-ietf-ipdvb-arch-04.txt Gorry Fairhurst 4 University of Aberdeen 5 Horst D. Clausen 6 TIC Systems 7 Bernhard Collini-Nocker 8 Hilmar Linder 9 University of Salzburg 10 Category: Informational May 2005 12 A Framework for transmission of IP datagrams over MPEG-2 Networks 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 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them other 30 than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright (C) The Internet Society (2004), All Rights Reserved 39 Abstract 40 This document describes an architecture for the transport of IP 41 Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has 42 has been widely accepted not only for providing digital TV services 43 but also as a subnetwork technology for building IP networks. 44 Examples of systems using MPEG-2 include the Digital Video 45 Broadcast (DVB) and Advanced Television Systems Committee (ATSC) 46 Standards for Digital Television. 48 The document identifies the need for a set of Internet standards 49 defining the interface between the MPEG-2 Transport Stream and an 50 IP subnetwork. It suggests a new encapsulation method for IP 51 datagrams and proposes protocols to perform IPv6/IPv4 address 52 resolution, to associate IP packets with the properties of the 53 Logical Channels provided by an MPEG-2 TS. 55 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 56 May 2005 58 Table of Contents 60 1. Introduction 61 1.1 Salient Features of the Architecture 62 2. Conventions Used in This Document 63 3. Architecture 64 3.1 MPEG-2 Transmission Networks 65 3.2 TS Logical Channels 66 3.3 Multiplexing and Re-Multiplexing 67 3.4 IP Datagram Transmission 68 3.5 Motivation 69 4. Encapsulation Protocol Requirements 70 4.1 Payload_Unit Delimitation 71 4.2 Length Indicator 72 4.3 Next Level Protocol Type 73 4.4 L2 Subnet Addressing 74 4.5 Integrity Check 75 4.6 Identification of Scope 76 4.7 Extension Headers 77 4.8 Summary of Requirements for Encapsulation 78 5. Address Resolution Functions 79 5.1 Address Resolution for MPEG-2 80 5.2 Scenarios for MPEG AR 81 5.2.1 Table-based AR over MPEG-2 82 5.2.2 Table-based AR over IP 83 5.2.3. Query/Response AR over IP 84 5.3 Unicast Address Scoping 85 5.4 AR Authentication 86 5.5 Requirements for Unicast AR over MPEG-2 87 6. Multicast Support 88 6.1 Multicast AR Functions 89 6.2 Multicast Address Scoping 90 6.3 Requirements for Multicast over MPEG-2 91 7. Summary 92 8. Security Considerations 93 8.1 Link Encryption 94 9. IANA Considerations 95 10. Acknowledgments 96 11. References 97 11.1 Normative References 98 11.2 Informative References 99 12. Authors' Addresses 100 13. IPR Notices 101 14. Copyright Statements 103 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 104 May 2005 106 [***RFC Editor Note: Remove following text prior to publication***] 108 Change Notice: 109 - v00 Original ipdvb WG Version 110 Document has been shortened and focused. 111 Some annexe material has been removed. 112 Restructured to describe the full framework. 113 New text describing the various scenarios. 114 Text added on various issues including compatibility 115 with services on DVB and ATSC (and different physical links). 117 - v01 Revised version following IETF-60 discussions 118 Removed redundant AR info and clarify AR reqs. 119 Multicast address scoping moved to section on 120 multicast AR. 121 Removed examples in AR appendix. 122 Added a small description of "e2e" management requirements. 123 Updated reference list. 124 Updated terminology to agree with that in ULE Spec. 125 Review by all authors to fix last known inconsistencies. 127 - v02 Revised version following WGLC discussions 128 Updated figure 1. 129 Fixed author's affiliation. 130 Fixed remaining typos and inconsistencies in page numbering. 131 Added DVB-S2, Open Cable and MHP references. 132 Removed a controversial paragraph in the Appendix. 134 - v03 Revised definitions following WGLC of ULE 136 - v04 Revised Security Considerations following IESG Review 137 Punctuation: added commas in section 1. 138 Reordered IANA, Author's Addresses sections. 139 Double space removed between words. 141 [***RFC Editor Note: End of text to be removed***] 143 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 144 May 2005 146 1. Introduction 148 This document identifies requirements and an architecture for the 149 transport of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. 150 The prime focus is the efficient and flexible delivery of IP 151 services over those subnetworks that use the MPEG-2 Transport 152 Stream (TS). 154 The architecture is designed to be compatible with services 155 based on MPEG-2, for example the Digital Video Broadcast (DVB) 156 architecture, the Advanced Television Systems Committee (ATSC) 157 system [ATSC; ATSC-G], and other similar MPEG-2 based transmission 158 systems. Such systems typically provide unidirectional (simplex) 159 physical and link layer standards, and have been defined for a wide 160 range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP- 161 TC], Satellite TV [ETSI-DVBS; ETSI-DVBS2, ATSC-S] and Cable 162 Transmission [ETSI-DVBC; ATSC-PSIP-TC; OPEN-CABLE] and data 163 transmission over MPEG-2 [ETSI-MHP]. 165 +-+-+-+-+------+------------+---+--+--+---------+ 166 |T|V|A|O| O | | O |S |O | | 167 |e|i|u|t| t | | t |I |t | | 168 |l|d|d|h| h | IP | h | |h | Other | 169 |e|e|i|e| e | | e |T |e |protocols| 170 |t|o|o|r| r | | r |a |r | native | 171 |e| | | | | | |b | | over | 172 |x| | | | | +---+----+-+ |l | |MPEG-2 TS| 173 |t| | | | | | | MPE | |e | | | 174 | | | | | +--+---+ +------+ | | | | 175 | | | | | | AAL5 |ULE|Priv. | | | | | 176 +-+-+-+-+---+------+ | +-+--+--+ | 177 | PES | ATM | |Sect. |Section| | 178 +-------+----------+---+------+-------+---------+ 179 | MPEG-2 TS | 180 +---------+-------+----------------+------------+ 181 |Satellite| Cable | Terrestrial TV | Other PHY | 182 +---------+-------+----------------+------------+ 184 Figure 1: Overview of the MPEG-2 protocol stack 186 Although many MPEG-2 systems carry a mixture of data types, MPEG-2 187 components may, and are, also used to build IP-only networks. 188 Standard system components offer advantages of improved 189 interoperability and larger deployment. However, often, MPEG-2 190 networks do not implement all parts of a DVB / ATSC system, 191 and may for instance support minimal, or no, signalling of 192 Service Information (SI) tables. 194 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 195 May 2005 197 1.1 Salient Features of the Architecture 199 The architecture defined in this document describes a set of 200 protocols that support transmission of IP packets over the MPEG-2 201 TS. Key characteristics of these networks are that they may 202 provide link-level broadcast capability, and that many supported 203 applications require access to a very large number of subnetwork 204 nodes. 206 Some, or all, of these protocols may also be applicable to other 207 subnetworks, e.g., other MPEG-2 transmission networks, regenerative 208 satellite links [ETSI-BSM], and some types of broadcast wireless 209 links. The key goals of the architecture are to reduce complexity 210 when using the system, while improving performance, increasing 211 flexibility for IP services, and providing opportunities for better 212 integration with IP services. 214 Since a majority of MPEG-2 transmission networks are 215 bandwidth-limited, encapsulation protocols must therefore add 216 minimal overhead to ensure good link efficiency while providing 217 adequate network services. They also need to be simple to minimize 218 processing, robust to errors and security threats, and extensible 219 to a wide range of services. 221 In MPEG-2 systems, TS Logical Channels, are identified by their PID 222 provide multiplexing, addressing, and error reporting. The TS 223 Logical Channel may also be used to provide Quality of Service 224 (QoS). Mapping functions are required to relate TS Logical Channels 225 to IP addresses, to map TS Logical Channels to IP-level QoS, and to 226 associate IP flows with specific subnetwork capabilities. An 227 important feature of the architecture is that these functions may be 228 provided in a dynamic way, allowing transparent integration with 229 other IP-layer protocols. Collectively, these will form an MPEG-2 230 TS Address Resolution (AR) protocol suite. 232 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 233 May 2005 235 2. Conventions Used In This Document 237 A2. Conventions Used In This Document 239 Adaptation Field: An optional variable-length extension field of 240 the fixed-length TS Packet header, intended to convey clock 241 references and timing and synchronization information as well as 242 stuffing over an MPEG-2 Multiplex [ISO-MPEG]. 244 ATSC: Advanced Television Systems Committee [ATSC]. A framework 245 and a set of associated standards for the transmission of video, 246 audio, and data using the ISO MPEG-2 standard. 248 DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. 249 A format for transmission of data and control information defined 250 by the ISO MPEG-2 standard that is carried in an MPEG-2 Private 251 Section. 253 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 254 associated standards published by the European Telecommunications 255 Standards Institute (ETSI) for the transmission of video, audio, 256 and data, using the ISO MPEG-2 Standard. 258 Encapsulator: A network device that receives PDUs and formats these 259 into Payload Units (known here as SNDUs) for output as a stream of 260 TS Packets. 262 Forward Direction: The dominant direction of data transfer over a 263 network path. Data transfer in the forward direction is called 264 "forward transfer". Packets travelling in the forward direction 265 follow the forward path through the IP network. 267 MAC: Medium Access and Control. The link layer header of the 268 Ethernet IEEE 802 standard of protocols, consisting of a 6B 269 destination address, 6B source address, and 2B type field (see 270 also NPA). 272 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. 273 A scheme that encapsulates PDUs, forming a DSM-CC Table Section. 274 Each Section is sent in a series of TS Packets using a single TS 275 Logical Channel. 277 MPEG-2: A set of standards specified by the Motion Picture 278 Experts Group (MPEG), and standardized by the International 279 Standards Organisation (ISO) [ISO-MPEG]. 281 NPA: Network Point of Attachment. Addresses primarily used for 282 station (Receiver) identification within a local network (e.g. 283 IEEE MAC address). An address may identify individual Receivers 284 or groups of Receivers. 286 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 287 May 2005 289 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 290 IPv4 or IPv6 datagrams, and other network packets. 292 PES: Packetized Elementary Steam [ISO-MPEG]. A format of MPEG-2 TS 293 packet payload usually used for video or audio information. 295 PID: Packet Identifier [ISO_MPEG]. A 13 bit field carried in the 296 header of TS Packets. This is used to identify the TS Logical 297 Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets 298 forming the parts of a Table Section, PES, or other Payload Unit 299 must all carry the same PID value. The all 1s PID value indicates 300 a Null TS Packet introduced to maintain a constant bit rate of 301 a TS Multiplex. There is no required relationship between the PID 302 values used for TS LogicalChannels transmitted using different 303 TS Multiplexes. 305 PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that 306 directly follows the TS Packet header. It contains the number of 307 bytes between the end of the TS Packet header and the start of a 308 Payload Unit. The presence of the Payload Pointer is indicated by 309 the value of the PUSI bit in the TS Packet header. The Payload 310 Pointer is present in DSM-CC, and Table Sections, it is not present 311 in TS Logical Channels that use the PES-format. 313 Private Section: A syntactic structure constructed in accordance 314 with Table 2-30 of [ISO-MPEG]. The structure may be used to 315 identify private information (i.e. not defined by [ISO-MPEG]) 316 relating to one or more elementary streams, or a specific MPEG-2 317 program, or the entire TS. Other Standards bodies, e.g. ETSI, 318 ATSC, have defined sets of table structures using the 319 private_section structure. A Private Section is transmitted as a 320 sequence of TS Packets using a TS Logical Channel. A TS Logical 321 Channel may carry sections from more than one set of tables. 323 PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey 324 information about services carried in a TS Multiplex. It is carried 325 in one of four specifically identified table section constructs 326 [ISO-MPEG], see also SI Table. 328 PU: Payload Unit. A sequence of bytes sent using a TS. Examples of 329 Payload Units include: an MPEG-2 Table Section or a ULE SNDU. 331 PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag 332 carried in the TS Packet header. A PUSI value of zero indicates 333 that the TS Packet does not carry the start of a new Payload Unit. 334 A PUSI value of one indicates that the TS Packet does carry the 335 start of a new Payload Unit. In ULE, a PUSI bit set to 1 also 336 indicates the presence of a one byte Payload Pointer (PP). 338 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 339 May 2005 341 Receiver: An equipment that processes the signal from a 342 TS Multiplex and performs filtering and forwarding of encapsulated 343 PDUs to the network-layer service (or bridging module when 344 operating at the link layer). 346 SI Table: Service Information Table [ISO-MPEG]. In this document, 347 this term describes a table that is used to convey information 348 about the services carried in a TS Multiplex, that has been defined 349 by another standards body. A Table may consist of one or more Table 350 Sections, however all sections of a particular SI Table must be 351 carried over a single TS Logical Channel [ISO-MPEG]. 353 SNDU: Subnetwork Data Unit [RFC3819]. An encapsulated PDU sent as 354 an MPEG-2 Payload Unit. 356 STB: Set-Top Box. A consumer equipment (Receiver) for reception of 357 digital TV services. 359 Table Section: A Payload Unit carrying all or a part of an SI or 360 PSI Table [ISO-MPEG]. 362 TS: Transport Stream [ISO-MPEG], a method of transmission at the 363 MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI 364 reference model. See also TS Logical Channel and TS Multiplex. 366 TS Header: The 4 byte header of a TS Packet [ISO-MPEG]. 368 TS Logical Channel: Transport Stream Logical Channel. In this 369 document, this term identifies a channel at the MPEG-2 level 370 [ISO-MPEG]. It exists at level 2 of the ISO/OSI reference model. 371 All packets sent over a TS Logical Channel carry the same PID value 372 (this value is unique within a specific TS Multiplex). According to 373 MPEG-2, some TS Logical Channels are reserved for specific 374 signalling. Other standards (e.g., ATSC, DVB) also reserve specific 375 TS Logical Channels. 377 TS Multiplex: In this document, this term defines a set of MPEG-2 378 TS Logical Channels sent over a single lower layer connection. 379 This may be a common physical link (i.e. a transmission at a 380 specified symbol rate, FEC setting, and transmission frequency) or 381 an encapsulation provided by another protocol layer (e.g. Ethernet, 382 or RTP over IP). The same TS Logical Channel may be repeated over 383 more than one TS Multiplex (possibly associated with a different 384 PID value) [ID-ipdvb-arch], for example to redistribute the same 385 multicast content to two terrestrial TV transmission cells. 387 TS Packet: A fixed-length 188B unit of data sent over a 388 TS Multiplex [ISO-MPEG]. Each TS Packet carries a 4B header, plus 389 optional overhead including an Adaptation Field, encryption details 390 and time stamp information to synchronise a set of related TS 391 Logical Channels. It is also referred to as a TS_cell. Each TS 392 Packet carries a PID value to associate it with a single TS Logical 393 Channel. 395 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 396 May 2005 398 3. Architecture 400 The following sections introduce the components of the MPEG-2 401 Transmission Network and relate these to a networking framework. 403 3.1 MPEG-2 Transmission Networks 405 There are many possible topologies for MPEG-2 Transmission 406 Networks. A number of example scenarios are briefly described 407 below, and the following text relates specific functions to this 408 set of scenarios. 410 A) Broadcast TV and Radio Delivery 411 The principal service in the Broadcast TV and Radio Delivery 412 scenario is Digital TV and/or Radio and their associated data [ID- 413 MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two 414 components: the contribution feed and the broadcast part. 415 Contribution feeds provide communication from a typically small 416 number of individual sites (usually at high quality) to the Hub of a 417 broadcast network. The traffic carried on contribution feeds is 418 typically encrypted, and is usually processed prior to being resent 419 on the Broadcast part of the network. The Broadcast part uses a star 420 topology centred on the Hub to reach a typically large number of 421 down-stream Receivers. Although such networks may provide IP 422 transmission, they do not necessarily provide access to the public 423 Internet. 425 B) Broadcast Networks used as an ISP 426 Another scenario resembles that above, but includes the provision of 427 IP services providing access to the public Internet. The IP traffic 428 in this scenario is typically not related to the digital TV/Radio 429 content, and the service may be operated by an independent operator 430 such as uni-directional file delivery or bi-directional ISP access. 431 The IP service must adhere to the full system specification used 432 for the broadcast transmission, including allocation of PIDs, and 433 generation of appropriate MPEG-2 control information (e.g. DVB and 434 ATSC SI tables). 436 C) Uni-directional Star IP Scenario 437 The Uni-directional Star IP Scenario utilises a Hub station to 438 provide a data network delivering a common bit stream to typically 439 medium-sized groups of Receivers. MPEG-2 transmission technology 440 provides the forward direction physical and link layers for this 441 transmission, the return link (if required) is provided by other 442 means. IP services typically form the main proportion of the 443 transmission traffic. Such networks do not necessarily implement 444 the MPEG-2 control plane, i.e. PSI/SI tables. 446 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 447 May 2005 449 D) Datacast Overlay 450 The Datacast Overlay scenario employs MPEG-2 physical and link 451 layers to provide additional connectivity such as uni-directional 452 multicast to supplement an existing IP-based Internet service. 453 Examples of such a network includes IP Datacast to mobile wireless 454 receivers [ID-MMUSIC-IMG]. 456 E) Point-to-Point Links 457 Point-to-Point connectivity may be provided using a pair of 458 transmit and receive interfaces supporting the MPEG-2 physical and 459 link layers. Typically the transmission from a sender is received 460 by only one or a small number of Receivers. Examples 461 include the use of transmit/receive DVB-S terminals to provide 462 satellite links between ISPs utilising BGP routing. 464 F) Two-Way IP Networks 465 Two-Way IP networks are typically satellite-based and star-based 466 utilising a Hub station to deliver a common bit stream to 467 medium-sized groups of receivers. A bi-directional service is 468 provided over a common air-interface. The transmission technology 469 in the forward direction at the physical and link layers is MPEG-2, 470 which may also be used in the return direction. Such systems also 471 usually include a control plane element to manage the (shared) 472 return link capacity. A concrete example is the DVB-RCS system 473 [ETSI-DVBRCS]. IP services typically form the main proportion of the 474 transmission traffic. 476 Scenarios A-D employ uni-directional MPEG-2 Transmission Networks. 477 For satellite-based networks, these typically have a star topology, 478 with a central Hub providing service to large numbers of down-stream 479 Receivers. Terrestrial networks may employ several transmission Hubs 480 each serving a particular coverage cell with a community of 481 Receivers. 483 From an IP viewpoint, the service is typically either 484 uni-directional multicast, or a bi-directional service in which some 485 complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used 486 to provide the return path from Receivers to the Internet. Routing 487 in this case could be provided using Uni-Directional Link Routing 488 (UDLR) [RFC3077]. 490 Note that only Scenarios A-B actually carry MPEG-2 video and audio 491 intended for reception by digital Set Top Boxes (STBs) as the 492 primary traffic. The other scenarios are IP-based data networks and 493 need not necessarily implement the MPEG-2 control plane. 495 Scenarios E-F provide two-way connectivity using the MPEG-2 496 Transmission Network. Such networks provide direct support for 497 bi-directional protocols above and below the IP layer. 499 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 500 May 2005 502 The complete MPEG-2 transmission network may be managed by a 503 transmission service operator. In such cases, the assignment of 504 addresses and TS Logical Channels at Receivers are usually under 505 the control of the service operator. Examples include a TV 506 operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 507 transmission networks are also used for private networks. These 508 typically involve a smaller number of Receivers and do not require 509 the same level of centralised control. Examples include companies 510 wishing to connect DVB-capable routers to form links within the 511 Internet (Scenario B). 513 3.2 TS Logical Channels 515 An MPEG-2 Transport Multiplex offers a number of parallel channels, 516 which are known here as TS Logical Channels. Each TS Logical 517 Channel is uniquely identified by the Packet ID, PID, value that is 518 carried in the header of each MPEG-2 TS Packet. The PID value is a 519 13 bit field and, thus the number of available channels ranges from 520 0 to 8191 decimal or 0x1FFF in hexadecimal, some of which are 521 reserved for transmission of SI tables. Non-reserved TS Logical 522 Channels may be used to carry audio [ISO-AUD], video [ISO-VID], IP 523 packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],or other data [ISO-DSMCC; 524 ETSI-DAT; ATSC-DAT]. The value 8191 decimal(0x1FFF) indicates a null 525 packet, used to maintain the physical bearer bit rate when there are 526 no other MPEG-2 TS packets to be sent. 528 TS-LC-A-1 /---\--------------------/---\ 529 \ / \ / \ 530 \ | | | | 531 TS-LC-A-2 ----------- | | ------------- 532 -------------------- | | ------------- 533 | | | | 534 /-------- / | ------------- 535 / \----/-------------------\----/ 536 TS-LC-A-3/ MPEG-2 TS MUX A 537 / 538 TS-LC / 539 ------------X 540 \ TS-LC-B-3 /---\------------------------/---\ 541 \ / \ / \ 542 \ | | | | 543 TS-LC-B-2 \----------- | | --------- 544 -------------------- | | --------- 545 | | | | 546 /-------- / | --------- 547 / \----/-----------------------\----/ 548 / MPEG-2 TS MUX B 549 TS-LC-B-1 551 Figure 2: Example showing MPEG-2 TS Logical Channels carried 552 Over 2 MPEG-2 TS Multiplexes. 554 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 555 May 2005 557 TS Logical Channels are independently numbered on each MPEG-2 TS 558 Multiplex (MUX). In most cases the data sent over the TS Logical 559 Channels will differ for different multiplexes. Figure 2 560 shows a set of TS Logical Channels sent using two MPEG-2 TS 561 Multiplexes (A and B). 563 There are cases where the same data may be distributed over two or 564 more multiplexes (e.g., some SI tables; multicast content which 565 needs to be received by Receivers tuned to either MPEG-2 TS; unicast 566 data were the Receiver may be in either/both two potentially 567 overlapping MPEG-2 transmission cells). In figure 2, each multiplex 568 carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may 569 differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be 570 common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3 571 carry identical content). 573 As can been seen, there are similarities between the way PIDs 574 are used and the operation of virtual channels in ATM. However, 575 unlike ATM, a PID defines a unidirectional broadcast channel and not 576 a point-to-point link. Contrary to ATM, there is, as yet, no 577 specified standard interface for MPEG-2 connection setup, or for 578 signaling mappings of IP flows to PIDs, or to set the Quality of 579 Service, QoS, assigned to a TS Logical Channel. 581 3.3 Multiplexing and Re-Multiplexing 583 In a simple example, one or more TS are processed by a MPEG-2 584 multiplexor resulting in a TS Multiplex. The TS Multiplex is 585 forwarded over a physical bearer towards one or more Receivers 586 (figure 3). 588 In a more complex example, the same TS may be fed to multiple MPEG-2 589 multiplexors and these may, in turn, feed other MPEG-2 multiplexors 590 (remultiplexing). Remultiplexing may occur in several places (and is 591 common in Scenarios A and B of section 3.1). One example is a 592 satellite that provides on-board processing of the TS packets, 593 multiplexing the TS Logical Channels received from one or more 594 uplink physical bearers (TS Multiplex) to one (or more in the case 595 of broadcast/multicast) down-link physical bearer (TS Multiplex). As 596 part of the remultiplexing process, a remultiplexor may renumber the 597 PID values associated with one or more TS Logical Channels to 598 prevent clashes between input TS Logical Channels with the same PID 599 carried on different input multiplexes. It may also modify and/or 600 insert new SI data into the control plane. 602 In all cases, the final result is a "TS Multiplex" which is 603 transmitted over the physical bearer towards the Receiver. 605 INTERNET DRAFT Architecture for IP transport over MPEG-2 Networks 606 May 2005 608 +------------+ +------------+ 609 | IP | | IP | 610 | End Host | | End Host | 611 +-----+------+ +------------+ 612 | ^ 613 +------------>+---------------+ | 614 + IP | | 615 +-------------+ Encapsulator | | 616 SI-Data | +------+--------+ | 617 +-------+-------+ |MPEG-2 TS Logical Channel | 618 | MPEG-2 | | | 619 | SI Tables | | | 620 +-------+-------+ ->+------+--------+ | 621 | -->| MPEG-2 | . . . 622 +------------>+ Multiplexor | | 623 MPEG-2 TS +------+--------+ | 624 Logical Channel |MPEG-2 TS Mux | 625 | | 626 Other ->+------+--------+ | 627 MPEG-2 -->+ MPEG-2 | | 628 TS --->+ Multiplexor | | 629 ---->+------+--------+ | 630 |MPEG-2 TS Mux | 631 | | 632 +------+--------+ +------+-----+ 633 |Physical Layer | | MPEG-2 | 634 |Modulator +---------->+ Receiver | 635 +---------------+ MPEG-2 +------------+ 636 TS Mux 637 Figure 3: An example configuration for a uni-directional 638 Service for IP transport over MPEG-2 640 3.4 IP Datagram Transmission 642 Packet data for transmission over an MPEG-2 Transport Multiplex is 643 passed to an Encapsulator, sometimes known as a Gateway. This 644 receives Protocol Data Units, PDUs, such as Ethernet frames or IP 645 packets, and formats each into a Sub-Network Data Unit, SNDU, by 646 adding an encapsulation header and trailer (see section 4). The 647 SNDUs are subsequently fragmented into a series of TS Packets. 649 To receive IP packets over a MPEG-2 TS Multiplex, a Receiver 650 needs to identify the specific TS Multiplex (physical link) and also 651 the TS Logical Channel (the PID value of a logical link). It is 652 common for a number of MPEG-2 TS Logical Channels to carry SNDUs, 653 and a Receiver must therefore filter (accept) IP packets sent with a 654 number of PID values, and must independently reassemble each SNDU. 656 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 657 May 2005 659 A Receiver that simultaneously receives from several TS Logical 660 Channels, must filter other unwanted TS Logical Channels by 661 employing for example specific hardware support. Packets for one IP 662 flow (i.e. a specific combination of IP source and destination 663 addresses) must be sent using the same PID. It should not be assumed 664 that all IP packets are carried on a single PID, as in some cable 665 modem implementations, and multiple PIDs must be allowed in the 666 architecture. Many current hardware filters limit the maximum number 667 of active PIDs (e.g. 32), although if needed, future systems may 668 reasonably be expected to support more. 670 In some cases, Receivers may need to select TS Logical Channels from 671 a number of simultaneously active TS Multiplexes. To do this, they 672 need multiple physical receive interfaces (e.g., RF front-ends and 673 demodulators). Some applications also envisage the concurrent 674 reception of IP Packets over other media that may not necessarily 675 use MPEG-2 transmission. 677 Bi-directional (duplex) transmission can be provided using a MPEG-2 678 Transmission Network by using one of a number of alternate return 679 channel schemes [DVB-RC]. Duplex IP paths may also be supported 680 using non-MPEG-2 return links (e.g. in Scenarios B-D of section 681 3.1). One example of such an application is that of Uni-Directional 682 Link Routing, UDLR [RFC3077]. 684 3.5 Motivation 686 The network layer protocols to be supported by this architecture 687 include: 688 (i) IPv4 Unicast packets, destined for a single end host 689 (ii) IPv4 Broadcast packets, sent to all end systems in an IP 690 network 691 (iii) IPv4 Multicast packets 692 (iv) IPv6 Unicast packets, destined for a single end host 693 (v) IPv6 Multicast packets 694 (vi) Packets with compressed IPv4 / IPv6 packet headers (e.g. 695 [RFC2507; RFC3095]) 696 (vii) Bridged Ethernet frames 697 (viii) Other network protocol packets (MPLS, potential new 698 protocols) 700 The architecture will provide: 701 (i) Guidance on which MPEG-2 features are pre-requisites for the IP 702 service, and identification of any optional fields that impact 703 performance/correct operation. 704 (ii) Standards to provide an efficient and flexible encapsulation 705 scheme that may be easily implemented in an Encapsulator or 706 Receiver. The payload encapsulation requires a type field for 707 the SNDU to indicate the type of packet and a mechanism to 708 signal which encapsulation is used on a certain PID. 710 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 711 May 2005 713 (iii) Standards to associate a particular IP address with a Network 714 Point of Attachment (NPA) that could or may not be a MAC 715 Address. This process resembles the IPv4 Address Resolution 716 Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR- 717 DRAFT]. In addition, the standard will be compatible with IPv6 718 autoconfiguration. 719 (iv) Standards to associate a MPEG-2 TS interface with one or more 720 specific TS Logical Channels (PID, TS Multiplex). Bindings are 721 required for both unicast transmission, and multicast 722 reception. In the case of IPv4, this must also support network 723 broadcast. To make the schemes robust to loss and state changes 724 within the MPEG-2 transmission network, a soft-state approach 725 may prove desirable. 726 (v) Standards to associate the capabilities of a MPEG-2 TS Logical 727 Channel with IP flows. This includes mapping of QoS functions, 728 such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS, 729 multi-homing and mobility. This capability could be associated 730 by the AR standard proposed above. 731 (vi) Guidance on Security for IP transmission over MPEG-2. The 732 framework must permit use of IPsec and clearly identify any 733 security issues concerning the specified protocols. The 734 security issues need to consider two cases: unidirectional 735 transfer (in which communication is only from the sending IP 736 end host to the receiving IP end host) and bi-directional 737 transfer. Consideration should also be given to security of the 738 TS Multiplex: the need for closed user groups and the use of 739 MPEG-2 TS encryption. 740 (vii) Management of the IP transmission, including standardised SNMP 741 MIBs and error reporting procedures. The need for and scope of 742 this is to be determined. 744 The specified architecture and techniques should be suited to a 745 range of systems employing the MPEG-2 TS, and may also suit other 746 (sub)networks offering similar transfer capabilities. 748 The following section, 4, describes encapsulation issues. 749 Sections 6 and 7 describe address resolution issues for unicast and 750 multicast respectively. 752 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 753 May 2005 755 4. Encapsulation Protocol Requirements 757 This section identifies requirements and provides examples of 758 mechanisms that may be used to perform the encapsulation of IPv4/v6 759 unicast and multicast packets over MPEG-2 Transmission Networks. 761 A network device, known as an Encapsulator receives PDUs (e.g. IP 762 Packets or Ethernet frames) and formats these into Subnetwork Data 763 Units,SNDUs. An encapsulation (or convergence) protocol transports 764 each SNDU over the MPEG-2 TS service and provides the appropriate 765 mechanisms to deliver the encapsulated PDU to the Receiver IP 766 interface. 768 In forming a SNDU, the encapsulation protocol typically adds 769 header fields that carry protocol control information, such 770 as the length of SNDU, Receiver address, multiplexing information, 771 payload type, sequence numbers etc. The SNDU payload is typically 772 followed by a trailer, which carries an Integrity Check (e.g., 773 Cyclic Redundancy Check, CRC). Some protocols also add additional 774 control information and/or padding to or after the trailer 775 (figure 4). 777 +--------+-------------------------+-----------------+ 778 | Header | PDU | Integrity Check | 779 +--------+-------------------------+-----------------+ 780 <--------------------- SNDU -------------------------> 782 Figure 4: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6 783 packet) to form an MPEG-2 Payload Unit. 785 Examples of existing encapsulation/convergence protocols include 786 ATM AAL5 [ITU-AAL5], and MPEG-2 MPE [ETSI-DAT]. 788 When required, a SNDU may be fragmented across a number of TS 789 Packets (figure 5). 791 +-----------------------------------------+ 792 |Encap Header|SubNetwork Data Unit (SNDU) | 793 +-----------------------------------------+ 794 / / \ \ 795 / / \ \ 796 / / \ \ 797 +------+----------+ +------+----------+ +------+----------+ 798 |MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 | 799 |Header| Payload | |Header| Payload | |Header| Payload | 800 +------+----------+ +------+----------+ +------+----------+ 802 Figure 5: Encapsulation of an PDU (e.g., IP packet) into a 803 Series of MPEG-2 TS Packets. Each TS Packet carries a header 804 with a common Packet ID (PID) value denoting the MPEG-2 TS 805 Logical Channel. 807 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 808 May 2005 810 The DVB family of standards currently defines a mechanism for 811 transporting an IP packet, or Ethernet frame using the 812 Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme 813 is also supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows 814 transmission of IP packets or (by using LLC) Ethernet frames by 815 encapsulation within a Table Section (with the format used by the 816 control plane associated with the MPEG-2 transmission). The MPE 817 specification includes a set of optional header components and 818 requires decoding of the control headers. This processing is 819 suboptimal for Internet traffic, since it incurs significant 820 receiver processing overhead and some extra link overhead [CLC99]. 822 The existing standards carry heritage from legacy implementations. 823 These have reflected the limitations of technology at the time of 824 their deployment (v.g. design decisions driven by audio/video 825 considerations rather than IP networking requirements). IPv6, MPLS, 826 and other network-layer protocols are not natively supported. 827 Together, these justify the development of a new encapsulation 828 that will be truly IP-centric. Carrying IP packets over a TS 829 Logical Channel involves several convergence protocol functions. 830 This section briefly describes these functions and highlights the 831 requirements for a new encapsulation. 833 4.1 Payload_Unit Delimitation 835 MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet 836 with a "start_of_payload_unit_indicator" (PUSI) [ISO-MPEG] carried 837 in the 4B TS Packet header. The PUSI is a 1 bit flag that has 838 normative meaning [ISO_MPEG] for TS Packets that carry PES Packets 839 or PSI/SI data. 841 When the payload of a TS Packet contains PES data, a PUSI value of 842 '1' indicates the TS Packet payload starts with the first byte of a 843 PES Packet. A value of '0' indicates that no PES Packet starts in 844 the TS Packet. If the PUSI is set to '1', then one, and only one, 845 PES Packet starts in the TS Packet. 847 When the payload of the TS Packet contains PSI data, a PUSI value of 848 '1' indicates the first byte of the TS Packet payload carries a 849 Payload Pointer (PP) that indicates the position of the first byte 850 of the Payload Unit (Table Section) being carried; if the TS Packet 851 does not carry the first byte of a Table Section, the PUSI is set to 852 '0', indicating that no Payload Pointer is present. 854 Using this PUSI bit, the start of the first Payload Unit in a TS 855 Packet is exactly known by the Receiver, unless that TS Packet has 856 been corrupted or lost in the transmission. In which case, the 857 payload is discarded until the next TS Packet is received with a 858 PUSI value of '1'. 860 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 861 May 2005 863 The encapsulation should allow packing of more than one SNDU into 864 the same TS Packet and should not limit the number of SNDUs that can 865 be sent in a TS Packet. In addition, it should allow an IP 866 Encapsulator to insert padding when there is an incomplete TS Packet 867 payload. A mechanism needs to be identified to differentiate this 868 padding from the case where another encapsulated SNDU follows. 870 A combination of the PUSI and a Length Indicator (see below) allows 871 an efficient MPEG-2 convergence protocol to receive accurate 872 delineation of packed SNDUs. The MPEG-2 standard [ISO_MPEG] does 873 not specify how private data should use the PUSI bit. 875 4.2 Length Indicator 877 Most services using MPEG-2 include a length field in the Payload 878 Unit header to allow the Receiver to identify the end of a Payload 879 Unit (e.g. PES Packet, Section, or an SNDU). 881 When parts of more than two Payload Units are carried in the same TS 882 Packet, only the start of the first is indicated by the Payload 883 Pointer. Placement of a Length Indicator in the encapsulation header 884 allows a Receiver to determine the number of bytes until the start 885 of the next encapsulated SNDU. This placement also provides the 886 opportunity for the Receiver to pre-allocate an appropriate-sized 887 memory buffer to receive the reassembled SNDU. 889 A Length Indicator is required, and should be carried in the 890 encapsulation header. This should support SNDUs of at least the MTU 891 size offered by Ethernet (currently 1500 bytes). Although the IPv4 892 and IPv6 packet format permits an IP packet of size up to 64 KB, 893 such packets are seldom seen on the current Internet. Since high 894 speed links are often limited by the packet forwarding rate of 895 routers, there has been a tendency for Internet core routers to 896 support MTU values larger than 1500 bytes. A value of 16 KB is not 897 uncommon in the core of the current Internet. This would seem a 898 suitable maximum size for an MPEG-2 transmission network. 900 4.3 Next Level Protocol Type 902 A key feature of the required encapsulation is to identify the 903 payload type being transported (e.g. to differentiate IPv4, IPv6, 904 etc). Most protocols use a type field to identify a specific 905 process at the next higher layer that is the originator or the 906 recipient of the payload (SNDU). This method is used by IPv4, 907 IPv6, and also by the original Ethernet protocol (DIX). OSI 908 uses the concept of a 'Selector' for this, (e.g. in the IEEE 909 802/ISO 8802 standards for CSMA/CD [LLC], although in this 910 case a SNAP (subnetwork access protocol) header is also 911 required for IP packets. 913 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 914 May 2005 916 A Next Level Protocol Type field is also required if compression 917 (e.g. Robust Header Compression [RFCROHC]) is supported. No 918 compression method has currently been defined that is directly 919 applicable to this architecture, however the ROHC framework 920 defines a number of header compression techniques that may yield 921 considerable improvement in throughput on links which have a limited 922 capacity. Since many MPEG-2 Transmission Networks are wireless, 923 the ROHC framework will be directly applicable for many 924 applications. The benefit of ROHC is greatest for smaller SNDUs 925 but does imply the need for additional processing at the Receiver 926 to expand the received compressed packets. The selected type 927 field should contain sufficient code points to support this 928 technique. 930 It is thus a requirement to include a Next Level Protocol Type field 931 in the encapsulation header. Such a field should specify values for 932 at least IPv4, IPv6, and must allow for other values (e.g., MAC- 933 level bridging). 935 4.4 L2 Subnet Addressing 937 In MPEG-2, the PID carried in the TS Packet header is used to 938 identify individual services with the help of SI tables. This was 939 primarily intended as a unidirectional (simplex) broadcast system. 940 A TS Packet stream carries either tables or one PES Packet stream 941 (i.e., compressed video or audio). Individual Receivers are not 942 addressable at this level. 944 IPv4 and IPv6 allocate addresses to end hosts and intermediate 945 systems (routers). Each system (or interface) is identified by a 946 globally assigned address. ISO uses the concept of a hierarchically 947 structured Network Service Access Point (NSAP) address to identify 948 an end host user process in an Internet environment. 950 Within a local network a completely different set of addresses for 951 the Network Point of Attachment (NPA) is used; frequently these NPA 952 addresses are referred to as Medium Access Control, MAC-level 953 addresses. In the Internet they are also called hardware addresses. 954 Whereas network layer addresses are used for routing, NPA addresses 955 are primarily used for Receiver identification. 957 Receivers may use the NPA of a received SNDU to reject unwanted 958 unicast packets within the (software) interface driver at the 959 Receiver, but must also perform forwarding checks based on the IP 960 address. IP multicast and broadcast may also filter using the 961 NPA, but Receivers must also filter unwanted packets at the network 962 layer based on source and destination IP addresses. This does not 963 imply that each IP address must map to a unique NPA (more than one 964 IP address may map to the same NPA). If a separate NPA address is 965 not required, the IP address is sufficient for both functions. 967 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 968 May 2005 970 If it is required to address an individual Receiver in an MPEG-2 971 transport system, this can be achieved either at the network level 972 (IP address) or via a hardware-level NPA address (MAC-address). If 973 both addresses used, they must be mapped either in a static or a 974 dynamic way (e.g., by an address resolution process). A similar 975 requirement may also exist to identify the PID and TS multiplex on 976 which services are carried. 978 Using an NPA address in a MPEG-2 TS may enhance security, in that 979 a particular PDU may be targeted for a particular Receiver by 980 specifying the corresponding Receiver NPA address. This is 981 however only a weak form of security, since the NPA filtering is 982 often reconfigurable (frequently performed in software), and may be 983 modified by a user to allow reception of specified (or all) packets, 984 similar to promiscuous mode operation in Ethernet. If security is 985 required, it should be applied at another place (e.g. link 986 encryption, authentication of address resolution, IPsec, transport 987 level security and/or application level security). 989 There are also cases where the use of a NPA is required (e.g. where 990 a system operates as a router) and if present this should be carried 991 in an encapsulation header where it may be used by Receivers as a 992 pre-filter to discard unwanted SNDUs. The addresses allocated do not 993 need to conform to the IEEE MAC address format. There are many cases 994 where a NPA is not required, and network layer filtering may be 995 used. A new encapsulation protocol should therefore support an 996 optional NPA. 998 4.5 Integrity Check 1000 For the IP service, the probability of undetected packet error 1001 should be small (or negligible) [RFC3819]. There is therefore 1002 a need for a strong integrity check (e.g. Cyclic Redundancy Check 1003 or CRC) to verify correctness of a received PDU [RFC3819]. 1004 Such checks should be sufficient to detect incorrect operation of 1005 the encapsulator and Receiver (including reassembly errors 1006 following loss/corruption of TS Packets), in addition to 1007 protecting from loss and/or corruption by the transmission 1008 network (e.g., multiplexors and links). 1010 Mechanisms exist in MPEG-2 Transmission Networks that may assist in 1011 detecting loss (e.g. the 4-bit continuity counter included in the 1012 MPEG-2 TS Packet header). 1014 An encapsulation must provide a strong integrity check for each 1015 IP packet. The requirements for usage of a link CRC are provided 1016 in [RFC3819]. To ease hardware implementation, this check should 1017 be carried in a trailer following the SNDU. A CRC-32 is sufficient 1018 for operation with up to a 12 KB payload, and may still provide 1019 adequate protection for larger payloads. 1021 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1022 May 2005 1024 4.6 Identification of Scope. 1026 The MPE section header contains information that could be used by 1027 The Receiver to identify the scope of the (MAC) address carried as a 1028 NPA, and prevent TS Packets intended for one scope being received by 1029 another. Similar functionality may be achieved by ensuring that only 1030 IP packets that do not have overlapping scope are sent on the same 1031 TS Logical Channel. In some cases, this may imply the use of 1032 multiple TS Logical Channels. 1034 4.7 Extension Headers 1036 The evolution of the Internet service may in future require 1037 additional functions. A flexible protocol should therefore provide a 1038 way to introduce new features when required, without having to 1039 provide additional out-of-band configuration. 1041 IPv6 introduced the concept of extension headers that carry extra 1042 information necessary/desirable for certain subnetworks. The DOCSIS 1043 cable specification also allows a MAC header to carry extension 1044 headers to build operator-specific services. It is thus a 1045 requirement for the new encapsulation to allow extension headers. 1047 4.8 Summary of Requirements for Encapsulation 1049 The main requirements for an IP-centric encapsulation include: 1050 - support of IPv4 and IPv6 packets 1051 - support for Ethernet encapsulated packets 1052 - flexibility to support other IP formats and protocols (e.g. 1053 ROHC, MPLS) 1054 - easy implementation using either hardware or software 1055 processing 1056 - low overhead/managed overhead 1057 - a fully specified algorithm that allows a sender to pack 1058 multiple packets per SNDU and to easily locate packet 1059 fragments 1060 - extensibility 1061 - compatibility with legacy deployments 1062 - ability to allow link encryption, when required 1063 - capability to support a full network architecture including 1064 data, control and management planes 1066 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1067 May 2005 1069 5. Address Resolution Functions 1071 Address Resolution (AR) provides a mechanism that associates L2 1072 information with the IP address of a system. Many L2 technologies 1073 employ unicast AR at the sender: an IP system wishing to send an IP 1074 packet encapsulates it and places it into a L2 frame. It then 1075 identifies the appropriate L3 adjacency (e.g. next hop router, end 1076 host) and determines the appropriate L2 adjacency (e.g. MAC address 1077 in Ethernet) to which the frame should be sent so that the packet 1078 gets across the L2 link. 1080 The L2 addresses discovered using AR are normally recorded in a data 1081 structure known as the arp/neighbor cache. The results of previous 1082 AR requests are usually cached. Further AR protocol exchanges may be 1083 required as communication proceeds to update or re-initialise the 1084 client cache state contents (i.e. purge/refresh the contents [ND]). 1085 For stability, and to allow network topology changes and client 1086 faults, the cache contents are normally "soft state", that is, they 1087 are aged with respect to time and old entries removed. 1089 In some cases (e.g. ATM, FR, X.25, MPEG-2 and many more), AR 1090 involves finding other information than the MAC address. This 1091 includes identifying other parameters required for L2 transmission, 1092 such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 1093 TS). 1095 Address resolution has different purposes for unicast and multicast. 1096 Multicast address resolution is not required for many L2 networks, 1097 but is required where MPEG-2 transmission networks carry IP 1098 multicast packets using more than one TS Logical Channel. 1100 5.1 Address Resolution for MPEG-2 1102 There are three elements to the L2 information required to perform 1103 AR before an IP packet is sent over a MPEG-2 TS. These are: 1105 (i) A Receiver ID (e.g. a 6B MAC/NPA address). 1106 (ii) A PID or index to find a PID. 1107 (iii) Tuner information (e.g. Transmit Frequency of the 1108 physical layer of a satellite/broadcast link 1110 Elements (ii) and (iii) need to be de-referenced via indexes to the 1111 Service Information (i.e. the Program Map Table, PMT) when the 1112 MPEG-2 Transmission Network includes remultiplexors that renumber 1113 the PID values of the TS Logical Channels that they process. (Note 1114 that PIDs are not intended to be end-to-end identifiers). However, 1115 although remultiplexing is common in broadcast TV networks 1116 (scenarios A and B), many private networks do not need to employ 1117 multiplexors that renumber PIDs (see section 3.2). 1119 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1120 May 2005 1122 The third element (iii) allows an AR client to resolve to a 1123 different MPEG TS Multiplex. This is used when there are several 1124 channels that may be used for communication (i.e. multiple 1125 outbound/inbound links). In a mesh system, this could be used to 1126 determine connectivity. This AR information is used in two ways at a 1127 Receiver: 1129 (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG 1130 TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set 1131 L2 filters to let traffic pass to the IP layer. This is used for 1132 unicast, and IPv4 subnet broadcast. 1134 (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, 1135 PID, MAC/NPA address), and allows the Receiver to set L2 filters 1136 enabling traffic to pass to the IP layer. A Receiver in a MPEG-2 TS 1137 Transmission Network needs to resolve the PID value and the tuning 1138 (if present)associated with a TS Logical Channel and (at least for 1139 unicast) the destination Receiver NPA address. 1141 A star topology MPEG-2 TS transmission network is illustrated below, 1142 with two Receivers receiving a forward broadcast channel sent by a 1143 Hub. (A mesh system has some additional cases.) The forward 1144 broadcast channel consists of a "TS Multiplex" (a single physical 1145 bearer) allowing communication with the terminals. These communicate 1146 using a set of return channels. 1148 Forward broadcast 1149 MPEG-2 TS \ 1150 ----------------X /-----\ 1151 / / \ 1152 | Receiver| 1153 /----------+ A | 1154 / \ / 1155 /-----\ / \-----/ 1156 / \ / 1157 | Hub |/ 1158 | +\ /-----\ 1159 \ / \ / \ 1160 \-----/ \ | Receiver| 1161 \-----------+ B | 1162 \ / 1163 \-----/ 1164 Figure 6: MPEG-2 Transmission Network with 2 Receivers 1166 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1167 May 2005 1169 There are three possibilities for unicast AR: 1171 (1) A system at a Receiver, A, needs to resolve an address of a 1172 system that is at the Hub; 1173 (2) A system at a Receiver, A, needs to resolve an address that is 1174 at another Receiver, B; 1175 (3) A host at the Hub needs to resolve an address that is at a 1176 Receiver. The sender (encapsulation gateway), uses AR to provide the 1177 the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, 1178 IPv4 subnet broadcast and multicast packets. 1180 If the Hub is an IP router, then case (1) and (2) are the same: 1181 The host at the Receiver does not know the difference. In these 1182 cases, the address to be determined is the L2 address of the device 1183 at the Hub to which the IP packet should be forwarded, and which 1184 then relays the IP packet back to the forward (broadcast) MPEG-2 1185 channel after AR (case 3). 1187 If the Hub is a L2 bridge, then case 2 still has to relay the IP 1188 packet back to the outbound MPEG-2 channel. The AR protocol needs to 1189 resolve the specific Receiver L2 MAC address of B, but needs to send 1190 this on a L2 channel to the Hub. This requires Receivers to be 1191 informed of the L2 address of other Receivers. 1193 An end host connected to the Hub needs to use the AR protocol to 1194 resolve the Receiver terminal MAC/NPA address. This requires the AR 1195 server at the Hub to be informed of the L2 addresses of other 1196 Receivers. 1198 5.2 Scenarios for MPEG AR 1200 An AR protocol may transmit AR information in three distinct ways: 1202 (i) An MPEG-2 signalling table transmitted at the MPEG-2 level 1203 (e.g. within the control plane using a Table; 1204 (ii) An MPEG-2 signalling table transmitted at the IP level 1205 (no implementations of this are known); 1206 (iii) An address resolution protocol transported over IP 1207 (as in ND for IPv6) 1209 There are three distinct cases in which AR may be used: 1211 (i) Multiple TS-Mux and the use of re-multiplexors; e.g. Digital 1212 Terrestrial, Satellite TV broadcast multiplexes. Many such systems 1213 employ remultiplexors that modify the PID values associated with TS 1214 Logical Channels as they pass through the MPEG-2 transmission 1215 network (as in Scenario A of Section 3.1). 1217 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1218 May 2005 1220 (ii) Tuner configuration(s) that are fixed or controlled by some 1221 other process. In these systems, the PID value associated with a TS 1222 Logical Channel may be known by the Sender. 1223 (iii) A service run over one TS Mux (i.e., uses only one PID, for 1224 example DOCSIS and some current DVB-RCS multicast systems). In these 1225 systems, the PID value of a TS Logical Channel may be known by the 1226 Sender. 1228 5.2.1 Table-based AR over MPEG-2 1230 In current deployments of MPEG-2 networks, information about the set 1231 of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually 1232 distributed via tables (service information, SI) sent using channels 1233 assigned a specific (well-known) set of PIDs. This was originally 1234 designed for audio/video distribution to STBs. This design requires 1235 access to control plane by processing the SI table information 1236 (carried in MPEG-2 section format [ISO_DSMCC]). The scheme 1237 reflects the complexity of delivering and co-ordinating the various 1238 TS Logical Channels associated with a multimedia TV programme. 1240 One possible requirement to provide TS multiplex and PID information 1241 for IP services is to integrate additional information into the 1242 existing MPEG-2 tables, or to define additional tables specific to 1243 the IP service. The DVB INT and the A/92 Specification from ATSC 1244 [ATSC-A92] are examples of the realization of such a requirement. 1246 5.2.2 Table-based AR over IP 1248 AR information could be carried over a TS data channel, (e.g. using 1249 an IP protocol similar to the Service Announcement Protocol, SAP). 1250 Implementing this independently of the SI tables, would ease 1251 implementation, by allowing it to operate on systems where IP 1252 processing is performed in a software driver. It may also allow the 1253 technique to be more easily adapted to other similar delivery 1254 networks. It also is advantageous for networks which use the MPEG-2 1255 TS, but do not necessarily support audio/video services and 1256 therefore do not need to provide interoperability with TV 1257 equipment (e.g. links used solely for connecting IP (sub)networks). 1259 5.2.3. Query/Response AR over IP 1261 A query/response protocol may be used at the IP level (similar to, 1262 or based on IPv6 Neighbor Advertisements of the ND protocol). The AR 1263 protocol may operate over an MPEG-2 TS Logical Channel using a 1264 previously agreed PID (e.g. configured, or communicated using a SI 1265 table). In this case, the AR could be performed by the target system 1266 itself (as in ARP and ND). This has good soft-state properties, and 1267 is very tolerant to failures. To find an address, a system sends a 1268 "query" to the network, and the "target" (or its proxy) replies. 1270 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1271 May 2005 1273 5.3 Unicast Address Scoping 1275 In some case, an MPEG-2 Transmission Network may support multiple IP 1276 networks. If this is the case, it is important to recognise the 1277 context (scope) within which an address is resolved, to prevent 1278 packets from one addressed scope leaking into other scopes. 1280 An examples of overlapping IP address assignments is the use of 1281 private unicast addresses (e.g. in IPv4, 10/8 prefix; 1282 172.16/12 prefix; 192.168/16 prefix). These should be confined to 1283 the area to which they are addressed. 1285 There is also a requirement for multicast address scoping 1286 (section 6.2). 1288 IP packets with these addresses must not be allowed to travel 1289 outside their intended scope, and may cause unexpected behaviour if 1290 allowed to do so. In addition, overlapping address assignments can 1291 arise using level 2 NPA addresses: 1293 (i) The NPA address must be unique within the TS Logical Channel. 1294 Universal IEEE MAC addresses used in Ethernet LANs are 1295 globally unique. If the NPA addresses are not globally 1296 unique, the same NPA address may be re-used by Receivers 1297 in different addressed areas. 1299 (ii) The NPA broadcast address (all 1s MAC address). Traffic with 1300 this address should be confined to one addressed area. 1302 Reception of unicast packets destined for another addressed area may 1303 lead to an increase in the rate of received packets by systems 1304 connected via the network. IP end hosts normally filter received 1305 unicast IP packets based on their assigned IP address. Reception of 1306 the additional network traffic may contribute to processing load but 1307 should not lead to unexpected protocol behaviour. It does however 1308 introduce a potential Denial of Service (DoS) opportunity. 1310 When the Receiver acts as an IP router, the receipt of such an IP 1311 packet may lead to unexpected protocol behaviour. This also provides 1312 a security vulnerability since arbitrary packets may be passed to 1313 the IP layer. 1315 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1316 May 2005 1318 5.4 AR Authentication 1320 In many AR designs authentication has been overlooked, because of 1321 the wired nature of most existing IP networks, which makes it easy 1322 to control hosts physically connected [RFC3819]. With wireless 1323 connections, this is changing: unauthorised hosts actually can 1324 claim L2 resources. The address resolution client (i.e. Receiver) 1325 may also need to verify the integrity and authenticity of the 1326 AR information that it receives. There are trust relationships 1327 both ways: clients need to know they have a valid server and 1328 that the resolution is valid. Servers should perform authorisation 1329 before they allow a L2 address to be used. 1331 The MPEG-2 Transmission Network may also require access control to 1332 prevent unauthorised use of the TS Multiplex, however, this is 1333 an orthogonal issue to address resolution. 1335 5.5 Requirements for Unicast AR over MPEG-2 1337 The requirement for AR over MPEG-2 networks include: 1338 (i) Use of a table-based approach to promote AR scaling. This 1339 requires definition of the frequency of update and volume of 1340 AR traffic generated. 1341 (ii) Mechanisms to install AR information at the server 1342 (unsolicited registration). 1343 (iii) Mechanisms to verify AR information held at the server 1344 (solicited responses). Appropriate timer values need to be 1345 defined. 1346 (iv) An ability to purge client AR information (after IP network 1347 renumbering, etc.). 1348 (v) Support of IP subnetwork scoping. 1349 (vi) Appropriate security associations to authenticate the sender. 1351 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1352 May 2005 1354 6. Multicast Support 1356 This section addresses specific issues concerning IPv4 and IPv6 1357 multicast [RFC1112] over MPEG-2 Transmission Networks. The primary 1358 goal of multicast support will be efficient filtering of IP 1359 multicast packets by the Receiver, and the mapping of IPv4 and 1360 IPv6 multicast addresses [RFC3171] to the associated PID value 1361 and TS Multiplex. 1363 The design should permit a large number of active multicast groups, 1364 and should minimise the processing load at the Receiver when 1365 filtering and forwarding IP multicast packets. For example, schemes 1366 that may be easily implemented in hardware would be beneficial, 1367 since these may relieve drivers and operating systems from 1368 discarding unwanted multicast traffic [RFC3819]. 1370 Multicast mechanisms are used at more than one protocol level. The 1371 upstream router feeding the MPEG-2 Encapsulator may forward 1372 multicast traffic on the MPEG-2 TS Multiplex using a static or 1373 dynamic set of groups. When static forwarding is used, the set 1374 of IP multicast groups may also be configured or set using SNMP, 1375 Telnet, etc. A Receiver normally uses either an IP group management 1376 protocol (IGMP [RFC 3376] for IPv4 or MLD [RFC2710][RFC3810] for 1377 IPv6) or a multicast routing protocol to establish tables that it 1378 uses to dynamically enable local forwarding of received groups. In 1379 a dynamic case, this group membership information is fed-back to the 1380 sender to enable it to start sending new groups and (if required) to 1381 update the tables that it produces for multicast AR. 1383 Appropriate procedures need to identify the correct action when the 1384 same multicast group is available on more than one TS Logical 1385 Channel. This could arise when different end hosts act as senders 1386 to contribute IP packets with the same IP group destination address. 1387 The correct behaviour for SSM [RFC3569] addresses must also be 1388 considered. It may also arise when a sender duplicates the same IP 1389 group over several TS Logical Channels (or even different TS 1390 Multiplexes), and in this case a Receiver may potentially receive 1391 more than one copy of the same packet. At the IP level, the 1392 host/router may be unaware of this duplication. 1394 6.1 Multicast AR Functions 1396 The functions required for multicast AR may be summarised as: 1398 (i) The Sender needs to know L2 mapping of a multicast group. 1399 (ii) The Receiver needs to know L2 mapping of a multicast group. 1401 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1402 May 2005 1404 In the Internet, multicast AR is normally a mapping function rather 1405 than a one-to-one association using a protocol. In Ethernet, the 1406 sender maps an IP address to a L2 MAC address, and the Receiver uses 1407 the same mapping to determine the L2 address to set a L2 1408 hardware/software filter entry. 1410 A typical sequence of actions for the dynamic case is: 1412 L3) Populate the IP L3 membership tables at the Receiver. 1413 L3) Receivers send/forward IP L3 membership tables to the Hub 1414 L3) Dynamic/static forwarding at hub/upstream router of IP L3 1415 groups 1416 L2) Populate the IP AR tables at the encapsulator gateway 1417 (i.e. Map IP L3 mcast groups to L2 PIDs) 1418 L2) Distribute the AR information to Receivers 1419 L2) Set Receiver L2 multicast filters for IP groups in the 1420 membership table. 1422 To be flexible AR must associate a TS Logical Channel (PID) not only 1423 with a group address, but possibly also a QoS class, and other 1424 appropriate MPEG-2 TS attributes. Explicit per group AR to 1425 individual L2 addresses is to be avoided. 1427 \ 1428 | 1429 +---+----+ +---------+ 1430 | Tuner |---+TS Table | . . . . 1431 +---+----+ +---------+ . 1432 | - . 1433 +--------+ +---------+ . 1434 | deMux |---+PID Table|........ 1435 +---+----+ +---------+ : 1436 | - : 1437 +--------+ +---------+ +------------+ 1438 |MPE/ULE |---+AR Cache-|---+ L2 Table | 1439 +---+----+ +---------+ +------------+ 1440 | | | 1441 +---+----+ +---+-----+ +---+----+ 1442 | IP | | AR | |IGMP/MLD| 1443 +---+----+ +---+-----+ +---+----+ 1444 | | | 1445 *------------+------------+ 1446 Figure 7: Receiver Processing Architecture 1448 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1449 May 2005 1451 6.2 Multicast Address Scoping 1453 As in unicast, it is important to recognise the context (scope) 1454 within which a multicast IP address is resolved, to prevent 1455 packets from one addressed scope leaking into other scopes. 1457 Examples of overlapping IP multicast address assignments, include: 1459 (i) Some multicast addresses, (e.g., scoped multicast addresses 1460 [RFC2365] that may be used in private networks). These are 1461 only valid within the addressed area (examples for IPv4 1462 include: 239/8; 224.0.0/24; 224.0.1/24). Similar cases 1463 exist for some IPv6 multicast addresses [RFC2375]. 1464 (ii) Scoped multicast addresses. Forwarding of these addresses 1465 is controlled by the scope associated with the address. 1466 (iii) Other non-IP protocols may also view sets of MAC multicast 1467 addresses as link-local, and may produce unexpected results 1468 if distributed across several private networks. 1470 IP packets with these addresses must not be allowed to travel 1471 outside their intended scope (see section 5.3). Performing multicast 1472 AR at the IP level can enable providers to offer independently 1473 scoped addresses and would need to use multiple Multicast AR 1474 servers, one per multicast domain. 1476 6.3 Requirements for Multicast over MPEG-2 1478 The requirements for supporting multicast include, but are not 1479 restricted to: 1481 (i) Encapsulating multicast packets for transmission using a 1482 MPEG-2 TS. 1483 (ii) Mapping IP multicast groups to the underlying MPEG-2 TS 1484 Logical Channel (PID) and the MPEG-2 TS Multiplex. 1485 (iii) Provide AR information to allow a Receiver to locate an 1486 IP multicast flow within an MPEG-2 TS Multiplex. 1487 (iv) Error Reporting. 1489 7. Summary 1491 This document describes the architecture for a set of protocols to 1492 perform efficient and flexible support for IP network services over 1493 networks built upon the MPEG-2 Transport Stream (TS). It also 1494 describes existing approaches. The focus is on IP networking, the 1495 mechanisms that are used and their applicability to supporting IP 1496 unicast and multicast services. 1498 The requirements for a new encapsulation of IPv4 and IPv6 packets is 1499 described, outlining the limitations of current methods and the need 1500 for a streamlined IP-centric approach. 1502 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1503 May 2005 1505 The architecture also describes MPEG-2 Address Resolution (AR) 1506 procedures to allow dynamic configuration of the sender and Receiver 1507 using an MPEG-2 transmission link/network. These support IPv4 and 1508 IPv6 services in both the unicast and multicast modes. Resolution 1509 protocols will support IP packet transmission using both the 1510 Multiprotocol Encapsulation (MPE), which is currently 1511 widely deployed, and also any IETF defined ULE encapsulation 1512 [ID-IPDVB-ULE]. 1514 8. Security Considerations 1516 When the MPEG-2 transmission network is not using a wireline 1517 network, the normal security issues relating to the use of wireless 1518 links for transport of Internet traffic should be considered 1519 [RFC3819]. 1521 End-to-end security (including confidentiality, authentication, 1522 integrity and access control) is closely associated with the end 1523 user assets that are protected. This close association cannot be 1524 ensured when providing security mechanisms only within a subnetwork 1525 (e.g. an MPEG-2 Transmission Network). Several security mechanisms 1526 that can be used end-to-end have already been deployed in the 1527 general Internet and are enjoying increasing use. Important examples 1528 include: 1530 - Transport Layer Security (TLS), which is primarily used to 1531 protect web commerce; 1532 - Pretty Good Privacy (PGP) and S/MIME, primarily used to protect 1533 and authenticate email and software distributions; 1534 - Secure Shell (SSH), used to secure remote access and file 1535 transfer; 1536 - IPsec, a general purpose encryption and authentication mechanism 1537 above IP that can be used by any IP application. 1539 However, subnetwork security is also important [RFC3819] and 1540 should be encouraged, on the principle that it is better than the 1541 default situation, which all too often is no security at all. 1542 Users of especially vulnerable subnets (such as radio/broadcast 1543 networks and/or shared media Internet access) often have control 1544 over at most one endpoint - usually a client - and therefore 1545 cannot enforce the use of end-to-end mechanisms. 1547 A related role for subnetwork security is to protect users against 1548 traffic analysis, i.e., identifying the communicating parties (by IP 1549 or MAC address) and determining their communication patterns, even 1550 when their actual contents are protected by strong end-to-end 1551 security mechanisms (this is important for networks such as 1552 broadcast/radio, where eaves-dropping is easy). 1554 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1555 May 2005 1557 Encryption performed at the Transport Stream (encrypting the 1558 payload of all TS-Packets with the same PID) encrypts/scrambles 1559 all parts of the SNDU, including the Layer 2 MAC/NPA address. 1560 Encryption at the section level in MPE may also optionally 1561 encrypt the Layer 2 MAC/NPA address in addition to the PDU data 1562 [ETSI-DAT]. In both cases, encryption of the MAC/NPA address, 1563 requires a Receiver to decrypt all encrypted data, before it can 1564 then filter the PDUs with the set of MAC/NPA addresses that it 1565 wishes to receive. This method also has the drawback that all 1566 Receivers must share a common encryption key. Encryption of the 1567 MPE MAC address is therefore not permitted in some systems 1568 (e.g. [ETSI-DVBRCS]). 1570 Where it is possible for an attacker to inject traffic into the 1571 subnetwork control plane, subnetwork security can additionally 1572 protect the subnetwork assets. This threat must specifically be 1573 considered for the protocols used for subnetwork control functions 1574 (e.g. address resolution, management, configuration). Possible 1575 threats include theft of service and denial of service; shared media 1576 subnets tend to be especially vulnerable to such attacks [RFC3819]. 1578 Appropriate security functions must therefore be provided for ipdvb 1579 control protocols [RFC3819], particularly when the control functions 1580 are provided above the IP-layer using IP-based protocols. Internet 1581 level security mechanisms (e.g.IPsec) can mitigate such threats. 1583 In general, End-to-End security is recommended for users of any 1584 communication path, especially when it includes a wireless/radio 1585 or broadcast link, where a range of security techniques already 1586 exist. Specification of security mechanisms at the application 1587 layer, or within the MPEG-2 transmission network are the concerns of 1588 organisations beyond the IETF. The complexity of any such security 1589 mechanisms should be considered carefully so that it will not unduly 1590 impact IP operations. 1592 8.1 Link Encryption 1594 Link level encryption of IP traffic is commonly used in 1595 broadcast/radio links to supplement End-to-End security (e.g. 1596 provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption 1597 and key exchange methods vary significantly, depending on the 1598 intended application.For example, DVB-S/DVB-RCS operated by 1599 Access Network Operators may wish to provide their customers 1600 (Internet Service Providers, ISP) with security services. Common 1601 security services are: terminal authentication and data 1602 confidentiality (for unicast and multicast) between an encapsulation 1603 gateway and Receivers. A common objective is to provide the same 1604 level of privacy as terrestrial links. An ISP may also wish to 1605 provide end-to-end security services to the end-users (based on the 1606 well known mechanisms such as IPsec). 1608 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1609 May 2005 1611 Therefore it is important to understand that both security solutions 1612 (Access Network Operators to ISP and ISP to end users) may co-exist. 1614 MPE supports optional link encryption [ETSI-DAT]. A pair of bits 1615 within the MPE protocol header indicate whether encryption 1616 (scrambling) is used. For encrypted PDUs the header bits 1617 indicate which of a pair of previously selected encryption keys 1618 is to be used. 1620 It is recommended that any new encapsulation defined by the 1621 IETF allows Transport Stream encryption and also supports optional 1622 link level encryption/authentication of the SNDU payload. In ULE 1623 [ID-IPDVB-ULE], this may be provided in a flexible way using 1624 Extension Headers. This requires definition of a mandatory 1625 header extension, but has the advantage that it decouples 1626 specification of the security functions from the encapsulation 1627 functions. This method also supports encryption of the NPA/MAC 1628 addresses. 1630 9. IANA Considerations 1632 A set of protocols which meet these requirements will require the 1633 IANA to make assignments. This document in itself, however, does not 1634 require any IANA involvement. 1636 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1637 May 2005 1639 10. Acknowledgments 1641 The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre 1642 Loyer, Luoma Juha-Pekka and and Rod Walsh for their detailed inputs. 1643 We also wish to acknowledge the input provided by the members of 1644 the IETF ipdvb WG. 1646 11. References 1648 11.1 Normative References 1650 [ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information Technology; Generic 1651 Coding of Moving Pictures and Associated Audio Information Systems", 1652 International Standards Organisation (ISO). 1654 [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting, European 1655 Telecommunications Standards Institute (ETSI). 1657 11.2 Informative References 1659 [ATSC] A/53C, "ATSC Digital Television Standard", Advanced 1660 Television Systems Committee (ATSC), Doc. A/53C, 2004. 1662 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1663 Systems Committee (ATSC), Doc. A/090, 2000. 1665 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1666 for the ATSC Data Broadcast Standard", Advanced Television Systems 1667 Committee (ATSC), Doc. A/91, 2001. 1669 [ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data 1670 Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 1671 2002. 1673 [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television 1674 Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 1675 2003. 1677 [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for 1678 Terrestrial Broadcast and Cable", Advanced Television Systems 1679 Committee (ATSC), Doc. A/65B, 2003. 1681 [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV 1682 (DTV) Applications over Satellite", Advanced Television Systems 1683 Committee (ATSC), Doc. A/80, 1999. 1685 [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet 1686 over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151. 1688 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1689 May 2005 1691 [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", 1692 European Telecommunications Standards Institute (ETSI). 1694 [ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB 1695 interaction channel for Cable TV distribution systems (CATV)", 1696 European Telecommunications Standards Institute (ETSI). 1698 [ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB); 1699 Interaction channel for satellite distribution systems", European 1700 Telecommunications Standards Institute (ETSI). 1702 [ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB); 1703 Modulation and Coding for DBS satellite systems at 11/12 GHz, 1704 European Telecommunications Standards Institute (ETSI). 1706 [ETSI-DVBS2] DCB, "Second generation framing structure, channel 1707 coding and modulation systems for Broadcasting, Interactive 1708 Services,News Gathering and Other Broadband Satellite Applications", 1709 European Telecommunications Standards Institute (ETSI). 1711 [ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing 1712 structure, channel coding and modulation for digital terrestrial 1713 television (DVB-T)", European Telecommunications Standards 1714 Institute (ETSI). 1716 [ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB); 1717 Multimedia Home Platform (MHP) Specification", v1.2.1, European 1718 Telecommunications Standards Institute (ETSI), June 2002. 1720 [ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification 1721 CNMS 1026 v1.0.0,(Work in Progress), April 2004. 1723 [ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Ultra Lightweight 1724 Encapsulation for transmission of IP datagrams over MPEG-2/DVB 1725 networks", Internet Draft, draft-ipdvb-ule-01.txt, Work in Progress, 1726 IPDVB WG. 1728 [ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for 1729 IP datagrams over MPEG-2 networks", Internet Draft, 1730 draft-fair-ipdvb-ar-01.txt, Work in Progress, IP-DVB WG. 1732 [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. 1733 Schulzrinne, "Protocol Requirements for Internet Media Guides", 1734 Internet Draft, draft-ietf-mmusic-img-req.txt, Work in Progress, 1735 MMUSIC WG. 1737 [ISO-AUD] ISO/IEC 13818-3:1995 "Information technology; Generic 1738 coding of moving pictures and associated audio information; Part 1739 3: Audio", International Standards Organisation (ISO). 1741 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1742 May 2005 1744 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology; Generic 1745 coding of moving pictures and associated audio information; Part 1746 6: Extensions for DSM-CC", International Standards Organisation 1747 (ISO). 1749 [ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology; 1750 Generic coding of moving pictures and associated audio information; 1751 Video", International Standards Organisation (ISO). 1753 [Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered 1754 Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390- 1755 401. 1757 [OPEN-CABLE] "Open Cable Application Platform Specification; 1758 OCAP 2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs, April 1759 2002. 1761 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 1762 RFC 793, September 1981. 1764 [RFC1112] Deering, S., "Host extensions for IP multicasting", 1765 STD 5, RFC 1112, August 1989. 1767 [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - 1768 Communication Layers", RFC 1122, October 1989. 1770 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1771 November 1990. 1773 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", 1774 BCP 23, RFC 2365, July 1998. 1776 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 1777 Assignments", RFC 2375, July 1998. 1779 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1780 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 1782 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1783 Compression", RFC 2507, February 1999. 1785 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., 1786 and Y. Zhang, "A Link-Layer Tunneling Mechanism for 1787 Unidirectional Links", RFC 3077, March 2001. 1789 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 1790 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1791 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 1792 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 1793 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 1794 RFC 3095, July 2001. 1796 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1798 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 1799 "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, 1800 RFC 3171, August 2001. 1802 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., 1803 and A. Thyagarajan, "Internet Group Management Protocol, 1804 Version 3", RFC 3376, October 2002. 1806 RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1807 Multicast (SSM)", RFC 3569, July 2003. 1809 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1810 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1812 [RFC3819] Phil Karn, C. Borman, G. Fairhurst, D. Grossman, R. 1813 Ludwig,J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for 1814 Internet Subnetwork Designers", RFC 3819, BCP 89. 1816 12. Authors' Addresses 1818 Marie J. Montpetit 1819 MJMontpetit.com 1820 Email: marie@mjmontpetit.com 1822 Godred Fairhurst 1823 Department of Engineering 1824 University of Aberdeen 1825 Aberdeen, AB24 3UE 1826 UK 1827 Email: gorry@erg.abdn.ac.uk 1828 Web: http://www.erg.abdn.ac.uk/users/gorry 1830 Horst D. Clausen 1831 TIC Systems 1832 Lawrence, Kansas 1833 Email: h.d.clausen@ieee.org 1835 Bernhard Collini-Nocker 1836 Department of Scientific Computing 1837 University of Salzburg 1838 Jakob Haringer Str. 2 1839 5020 Salzburg 1840 Austria 1841 Email: bnocker@cosy.sbg.ac.at 1842 Web: http://www.network-research.org 1844 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1845 May 2005 1847 Hilmar Linder 1848 Department of Scientific Computing 1849 University of Salzburg 1850 Jakob Haringer Str. 2 1851 5020 Salzburg 1853 Austria 1854 Email: hlinder@cosy.sbg.ac.at 1855 Web: http://www.network-research.org 1857 13. IPR Notices 1859 Intellectual Property Statement 1861 The IETF takes no position regarding the validity or scope of any 1862 Intellectual Property Rights or other rights that might be claimed 1863 to pertain to the implementation or use of the technology described 1864 in this document or the extent to which any license under such 1865 rights might or might not be available; nor does it represent that 1866 it has made any independent effort to identify any such rights. 1867 Information on the procedures with respect to rights in RFC 1868 documents can be found in BCP 78 and BCP 79. 1870 Copies of IPR disclosures made to the IETF Secretariat and any 1871 assurances of licenses to be made available, or the result of an 1872 attempt made to obtain a general license or permission for the use 1873 of such proprietary rights by implementers or users of this 1874 specification can be obtained from the IETF on-line IPR repository 1875 at http://www.ietf.org/ipr. 1877 The IETF invites any interested party to bring to its attention any 1878 copyrights, patents or patent applications, or other proprietary 1879 rights that may cover technology that may be required to implement 1880 this standard. Please address the information to the IETF at ietf- 1881 ipr@ietf.org. 1883 Disclaimer of Validity 1885 This document and the information contained herein are provided on an 1886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1888 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1889 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1890 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1893 14. Copyright Statement 1895 Copyright (C) The Internet Society (2004). This document is 1896 subject to the rights, licenses and restrictions contained in 1897 BCP 78, and except as set forth therein, the authors retain all 1898 their rights. 1900 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1901 May 2005 1903 Appendix A: MPEG-2 Encapsulation Mechanisms 1905 To transmit packet data over an MPEG-2 transmission network requires 1906 that individual PDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet 1907 Frames) are encapsulated using a convergence protocol. The following 1908 encapsulations are currently standardised for MPEG-2 transmission 1909 networks: 1911 (i) Multi-Protocol Encapsulation (MPE). 1912 The Multi-Protocol Encapsulation, MPE, specification of DVB 1913 [ETSI-DAT] uses private Sections for the transport of IP 1914 packets and uses encapsulation that is similar to the IEEE 1915 LAN/MAN standards [LLC]. Data packets are encapsulated in 1916 datagram sections that are compliant with the DSMCC section 1917 format for private data. Some Receivers may exploit section 1918 processing hardware to perform a first-level filter of the 1919 packets that arrive at the Receiver. 1921 This encapsulation makes use of a MAC-level Network Point of 1922 Attachment address. The address format conforms to the 1923 ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC address 1924 field contains the MAC address of the destination; it is 1925 distributed over six 8-bit fields, labelled MAC_address_1 to 1926 MAC_address_6. The MAC_address_1 field contains the most 1927 significant byte of the MAC address, while MAC_address_6 1928 contains the least significant byte. How many of these 1929 bytes are significant is optional and defined by the value 1930 of the broadcast descriptor table [SI-DAT] sent separately 1931 over another MPEG-2 TS within the TS multiplex. 1933 MPE is currently a widely deployed scheme. Due to 1934 Investments in existing systems, usage is likely to continue 1935 in current and future MPEG-2 Transmission Networks. ATSC 1936 provides a scheme similar to MPE [ATSC-DAT] with some small 1937 differences. 1939 INTERNET DRAFT Architecture for IP transport over MPEG-2 networks 1940 May 2005 1942 (ii) Data Piping. 1944 The Data Piping profile [ETSI-DAT] is a minimum overhead, 1945 simple and flexible profile that makes no assumptions 1946 concerning the format of the data being sent. In this 1947 profile, the Receiver is intended to provide PID filtering, 1948 packet reassembly according to [DVB-SIDAT-368], error 1949 detection and optional Conditional Access (link encryption). 1951 The specification allows the user data stream to be 1952 unstructured or organized into packets. The specific 1953 structure is transparent to the Receiver. It may conform to 1954 any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, 1955 etc. 1957 (iii) Data Streaming. 1958 The data broadcast specification profile [ETSI-DAT] for PES 1959 tunnels (Data Streaming) supports unicast and multicast data 1960 services that require a stream-oriented delivery of data 1961 packets. This encapsulation maps an IP packet into a single 1962 PES Packet payload. 1964 Two different types of PES headers can are selected via the 1965 stream_id values [ISO-MPEG]. The private_stream_2 value 1966 permits the use of the short PES header with limited 1967 overhead, while the private_stream_1 value makes available 1968 the scrambling control and the timing and clock reference 1969 features of the PES layer.