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