idnits 2.17.1 draft-fair-ipdvb-ar-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1146. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (October 2005) is 6768 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ETSI-DVB' is mentioned on line 148, but not defined == Missing Reference: 'IEEE-802.3' is mentioned on line 163, but not defined == Missing Reference: 'DIX' is mentioned on line 167, but not defined == Missing Reference: 'ETSI-DAT1' is mentioned on line 1099, but not defined == Missing Reference: 'ATSC-DAT' is mentioned on line 1080, but not defined == Missing Reference: 'DVB-DAT' is mentioned on line 793, but not defined == Missing Reference: 'DOCSIS' is mentioned on line 429, but not defined == Missing Reference: 'RFC-ARP' is mentioned on line 684, but not defined == Missing Reference: 'RFC-ND' is mentioned on line 984, but not defined == Missing Reference: 'RFC-ASYM' is mentioned on line 750, but not defined == Missing Reference: 'IP-IPDVB-ULE' is mentioned on line 855, but not defined == Missing Reference: 'LLC' is mentioned on line 938, but not defined == Missing Reference: 'RFC1122' is mentioned on line 1070, but not defined == Missing Reference: 'ID-MMUSIC-IMG' is mentioned on line 1075, but not defined == Missing Reference: 'ATSC-DATG' is mentioned on line 1083, but not defined == Missing Reference: 'ATSC-A92' is mentioned on line 1087, but not defined == Missing Reference: 'ATSC-G' is mentioned on line 1091, but not defined == Missing Reference: 'ATSC-PSIP-TC' is mentioned on line 1095, but not defined == Unused Reference: 'RFC1112' is defined on line 1023, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-DAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-MHP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI-SI' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-DSMCC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG2' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- No information found for draft-ipdvb-arch - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-bb-deployment-scenarios-00 Summary: 5 errors (**), 0 flaws (~~), 22 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gorry Fairhurst 2 Internet Draft University of Aberdeen 3 Document: draft-fair-ipdvb-ar-04.txt Marie-Jose Montpetit 4 Motorola 5 Hidetaka Izumiyama 6 Wishnet 8 Category: Internet Draft Expires October 2005 10 Address Resolution for IP datagrams over MPEG-2 networks 12 Status of this Draft 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes the process of binding/associating IPv4/IPv6 36 addresses with MPEG-2 Transport Streams (TS). This procedure is 37 known as Address Resolution (AR), or Neighbour Discovery (ND). Such 38 address resolution complements the higher layer resource discovery 39 tools that are used to advertise IP sessions. In MPEG-2 networks, an 40 IP address must be associated with a Packet ID (PID) and a specific 41 Transmission Multiplex The document reviews current methods. It also 42 describes the interaction with well-known protocols for address 43 management including DHCP, ARP, and NDP, and provides guidance on 44 usage. 46 Table of Contents 48 1. Introduction 49 2. Convention used in the document 50 3. Address Resolution Requirement 51 3.1 Unicast Support 52 3.2 Multicast Support 53 4. MPEG-2 Address Resolution 54 4.1 Static configuration. 55 4.1.1 MPEG-2 Cable Networks 56 4.2 MPEG-2 Table-Based Address Resolution 57 4.2.1 IP/MAC Notification Table (INT) and its usage 58 4.2.2 Multicast Mapping Table (MMT) and its usage 59 4.2.3 Application Information Table (AIT) and its usage 60 4.2.4 Comparison of SI/PSI table approaches 61 4.3 IP-based resolution of TS Logical Channels 62 4.3.1 IP-based multicast resolution of TS Logical Channels 63 5. Mapping IP addresses to NPA/MAC addresses 64 5.1 Uni-directional links supporting uni-directional connectivity 66 5.2 Uni-directional links with bi-directional connectivity 67 5.3 Bi-directional links 68 5.4 IP Multicast AR 69 6. Link Layer Support 70 6.1 ULE without a destination MAC/NPA address (D=1) 71 6.2 ULE with a destination NPA/MAC address (D=0) 72 6.3 MPE without LLC/SNAP Encapsulation 73 6.4 MPE with LLC/SNAP Encapsulation 74 6.5 ULE with Bridging Header Extension (D=1) 75 6.6 ULE with Bridging Header Extension and NPA Address (D=0) 76 6.7 MPE with LLC/SNAP and Bridging 77 7. Conclusions 78 8. Security Considerations 79 9. Acknowledgements 80 10. References 81 11. Author's Addresses 82 12. IPR Notices 83 13. Copyright Statements 84 14. IANA Considerations 86 Appendices 87 1. Introduction 89 The MPEG-2 Transport Stream (TS) provides a time-division 90 multiplexed (TDM) stream that may contain audio, video and data 91 information, including encapsulated IP datagrams. It is defined in 92 specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 frame, known 93 as a TS Packet, contains a 4 byte header and 188 bytes of payload. 94 Each TS Packet is associated with a single TS Logical Channel, 95 identified by a 13 bit Packet ID (PID) value that is carried in the 96 MPEG-2 TS Packet header. 98 The MPEG-2 standard also defines a control plane that may be used to 99 transmit control information to Receivers using System Information 100 (SI) Tables [ETSI-SI, ETSI-SI1], or Program Specific Information 101 (PSI) Tables. 103 To utilise the MPEG-2 TS as an IP link, a sender must associate an 104 IP address with a particular Transmission Multiplex, and within the 105 multiplex identify the specific PID to be used. This document calls 106 this mapping Address Resolution (AR) [ipdvb-arch]. In some AR 107 schemes, the MPEG-2 TS address space is sub-divided into logical 108 contexts known as Platforms. Each platform associates an IP service 109 provider with a separate context that share a common MPEG-2 TS (use 110 the same PID value). 112 MPEG-2 Receivers may use a Network Point of Attachment (NPA) [ipdvb- 113 arch] to uniquely identify the L2 node within the MPEG-2 114 transmission network. An example of an NPA is the IEEE Medium Access 115 Control (MAC) address. Where such addresses are used, these must 116 also be signalled by the AR procedure. Finally, address resolution 117 may need to signal the format of the data being transmitted, for 118 example, the encapsulation, any L2 encryption method and any 119 compression scheme [ID-IPDVB-ARCH]. 121 The remainder of the document describes current mechanisms and their 122 use to associate an IP address with the corresponding TS Multiplex, 123 PID value, the MAC address and/or Platform ID. A range of approaches 124 is described, including Layer-2 methods (utilising MPEG-2 SI 125 tables), and protocols at the IP level (including the IPv4 Address 126 Resolution Protocol, ARP [RFC826] and the IPv6 Neighbor Discovery 127 Protocol, NDP [RFC2461]). Interactions and dependencies between 128 these methods and the encapsulation methods are described. 130 2. Conventions used in this document 132 AIT: Application Information Table specified by the Multimedia 133 Home Platform (MHP) specifications [ETSI-MHP]. This table may 134 carry IPv4/IPv6 to MPEG-2 TS address resolution information. 136 ATSC: Advanced Television Systems Committee [ATSC]. A framework and 137 a set of associated standards for the transmission of video, audio, 138 and data using the ISO MPEG-2 standard. 140 b: bit. For example, one byte consists of 8b. 142 B: Byte. Groups of bytes are represented in Internet byte order. 144 DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A 145 format for transmission of data and control information in an MPEG-2 146 Private Section, defined by the ISO MPEG-2 standard. 148 DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of 149 associated standards published by the European Telecommunications 150 Standards Institute (ETSI) for the transmission of video, audio, and 151 data, using the ISO MPEG-2 Standard. 153 DVB-RCS: Digital Video Broadcast Return Channel via Satellite. 154 A bi-directional IPv4/IPv6 service employing low-cost Receivers. 156 Encapsulator: A network device that receives PDUs and formats these 157 into Payload Units (known here as SNDUs) for output as a stream of 158 TS Packets. 160 INT: Internet/MAC Notification Table. A uni-directional 161 addressing resolution mechanism using SI and/or PSI Tables. 163 MAC: Medium Access Control [IEEE-802.3]. A link layer protocol 164 defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). 166 MAC Header: The link layer header of the IEEE 802.3 standard [IEEE- 167 802.3] or Ethernet v2 [DIX]. It consists of a 6B destination 168 address, 6B source address, and 2B type field (see also NPA, LLC). 169 MAC: Medium Access and Control of the Ethernet IEEE 802 standard 170 of protocols (see also NPA). 172 MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia 173 receiver, that may (in some cases) support IPv4/IPv6 services. 175 MMT: Multicast Mapping Table (proprietary extension to DVB-RCS 176 defining an AR table that maps IPv4 multicast addresses to PID 177 values). 179 MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A 180 scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each 181 Section is sent in a series of TS Packets using a single TS Logical 182 Channel. 184 MPEG-2: A set of standards specified by the Motion Picture Experts 185 Group (MPEG), and standardized by the International Standards 186 Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). 188 NPA: Network Point of Attachment. In this document, refers to a 6 189 byte destination address (resembling an IEEE MAC address) within the 190 MPEG-2 transmission network that is used to identify individual 191 Receivers or groups of Receivers. 193 PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the 194 header of TS Packets. This is used to identify the TS Logical 195 Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets 196 forming the parts of a Table Section, PES, or other Payload Unit 197 must all carry the same PID value. The all 1s PID value indicates a 198 Null TS Packet introduced to maintain a constant bit rate of a TS 199 Multiplex. There is no required relationship between the PID values 200 used for TS Logical Channels transmitted using different TS 201 Multiplexes. The all 1s PID value indicates a Null TS Packet 202 introduced to maintain a constant bit rate of a TS Multiplex. There 203 is no required relationship between the PID values used for TS 204 Logical Channels transmitted using different TS Multiplexes. 206 Private Section: A syntactic structure constructed in accordance 207 with Table 2-30 of [ISO-MPEG2]. The structure may be used to 208 identify private information (i.e. not defined by [ISO-MPEG2]) 209 relating to one or more elementary streams, or a specific MPEG-2 210 program, or the entire Transport Stream. Other Standards bodies, 211 e.g. ETSI, ATSC, have defined sets of table structures using the 212 private_section structure. A Private Section is transmitted as a 213 sequence of TS Packets using a TS Logical Channel. A TS Logical 214 Channel may carry sections from more than one set of tables. 216 PSI: Program Specific Information [ISO-MPEG2]. PSI is used to convey 217 information about services carried in a TS Multiplex. It is carried 218 in one of four specifically identified table section constructs 219 [ISO-MPEG2], see also SI Table. 221 PSI: Program Specific Information [ISO-MPEG2]. PSI is used to 222 convey information about services carried in a TS Multiplex. 223 It is carried in one of four specifically identified table 224 section constructs [ISO-MPEG2], see also SI Table. 226 Receiver: Equipment that processes the signal from a TS Multiplex 227 and performs filtering and forwarding of encapsulated PDUs to the 228 network-layer service (or bridging module when operating at the link 229 layer). 231 SI Table: Service Information Table [ISO-MPEG2]. In this document, 232 this term describes a table that is been defined by another 233 standards body to convey information about the services carried in a 234 TS Multiplex. A Table may consist of one or more Table Sections, 235 however, all sections of a particular SI Table must be carried over 236 a single TS Logical Channel [ISO-MPEG2]. 238 SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 239 Payload Unit. 241 Table Section: A Payload Unit carrying all or a part of an SI or PSI 242 Table [ISO-MPEG2]. 244 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 245 MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI 246 reference model. See also TS Logical Channel and TS Multiplex. 247 to two terrestrial TV transmission cells. 249 TS Logical Channel: Transport Stream Logical Channel. In this 250 document, this term identifies a channel at the MPEG-2 level 251 [ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. 252 All packets sent over a TS Logical Channel carry the same PID 253 value (this value is unique within a specific TS Multiplex). The 254 term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the 255 content carried by a specific TS Logical Channel (see, ULE Stream). 256 Some PID values are reserved (by MPEG-2) for specific signalling. 257 Other standards (e.g., ATSC, DVB) also reserve specific PID values. 259 TS Multiplex: In this document, this term defines a set of MPEG-2 TS 260 Logical Channels sent over a single lower layer connection. This may 261 be a common physical link (i.e. a transmission at a specified symbol 262 rate, FEC setting, and transmission frequency) or an encapsulation 263 provided by another protocol layer (e.g. Ethernet, or RTP over IP). 264 The same TS Logical Channel may be repeated over more than one TS 265 Multiplex (possibly associated with a different PID value) [ID- 266 ipdvb-arch], for example to redistribute the same multicast content 267 to two terrestrial TV transmission cells. 269 TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex 270 [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional 271 overhead including an Adaptation Field, encryption details and time 272 stamp information to synchronise a set of related TS Logical 273 Channels. 275 UDL: Unidirectional link: A one-way transmission IP over DVB link, 276 e.g., a broadcast satellite link. 278 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE 279 encapsulated PDUs. ULE Streams may be identified by definition of 280 a stream_type in SI/PSI [ISO_MPEG2]. 282 3. Address Resolution Requirements 284 The MPEG IP address resolution process is independent of the choice 285 of encapsulation and needs to support a set of IP over MPEG-2 286 encapsulation formats, including MPE [ETSI-DAT,ETSI-DAT1, ATSC-DAT]) 287 and the IETF-defined Ultra Lightweight Encapsulation (ULE) [ID- 288 ARCH,ID-ULE]. 290 The general IP over MPEG-2 AR requirements are summarized below: 292 - A scalable and efficient transmission. 293 - A method to represent the AR information. 294 - Support for scoping of the addresses. 295 - Incremental update of clients with AR information. 296 - Procedures for purging stale client AR information. 297 - A method to identify the Server sourcing AR information. 298 - A method to install AR information at the AR server 299 (unsolicited registration). 300 - Security associations to authenticate the AR information. 302 An MPEG-2 Transmission Network may support multiple IP networks. 303 If this is the case, it is important to recognise the context 304 (scope) within which an address is resolved, to prevent packets from 305 one addressed scope leaking into other scopes. Examples of 306 overlapping IP address assignments include: 308 (i) Private unicast addresses (e.g. in IPv4, 10/8 prefix; 309 172.16/12 prefix; 192.168/16 prefix) should be confined to 310 one addressed area. IPv6 also defines link-local addresses that 311 must not be forwarded beyond the link on which they were first 312 sent. 314 (ii) Some multicast addresses, (e.g., the scoped multicast 315 addresses sometimes used in private networks). These are 316 only valid within an addressed area (examples for IPv4 317 include; 239/8; 224.0.0/24; 224.0.1/24). Similar cases 318 exist for some IPv6 multicast addresses. 320 (iii)Scoped multicast addresses. Forwarding of these addresses 321 is controlled by the scope associated with the address. 323 Overlapping address assignments may also occur at L2, where the same 324 NPA/MAC address is used to identify multiple receivers [ID-IPDVB- 325 ARCH]: 327 (i) An NPA unicast address must be unique within the addressed 328 area. The IEEE assigned MAC addresses used in Ethernet LANs are 329 Globally unique. If the NPA addresses are not globally unique, 330 an NPA address must only be re-used by receivers in 331 different addressed (scoped) areas. 333 (ii) The NPA broadcast address (all 1 MAC address). Traffic 334 with this address should be confined to one addressed area. 336 (iii) IP and other protocols may view sets of MAC multicast 337 addresses as link-local, and may produce unexpected results if 338 frames with these address are distributed across several 339 private networks. 341 Reception of unicast packets destined for another addressed area 342 will lead to an increase in the rate of received packets by systems 343 connected via the network. Reception of the additional network 344 traffic may contribute to processing load, but should not lead to 345 unexpected protocol behaviour. It does however introduce a potential 346 Denial of Service (DoS) opportunity. When the Receiver operates as 347 an IP router, the receipt of such a packet can lead to unexpected 348 protocol behaviour. 350 3.1 Unicast Support 352 Unicast address resolution may be required at two levels. At the 353 upper level, the AR procedure needs to associate an IP address with 354 a specific NPA/MAC address. At the lower level, the IP (or MAC) 355 address needs to be associated with a specific TS Logical Channel 356 (PID value) and the corresponding TS Multiplex. 358 The same unicast IP address may be associated with more than one TS 359 Logical Channel within the same scope [DVB-DAT]. These may have 360 different content, but there is also the possibility of a Receiver 361 receiving duplicated copies of packets. 363 3.2 Multicast Support 365 Multicast is an important application for MPEG-2 Transmission 366 Networks, since it exploits the advantages of native support for 367 link broadcast. 369 Multicast address resolution occurs at one level in associating a 370 specific L2 address with am IP Group Destination Address (section 371 5). In IPv4 and IPv6 over Ethernet, this association is normally a 372 direct mapping, and this is the default method also specified in 373 both ULE [ID-IPDVB-ULE] and in MPE [ETSI-DAT]. 375 Address resolution must also occur at the MPEG-2 level (section 4). 376 The goal of this multicast address resolution is the association of 377 an IPv4 or IPv6 multicast address with a specific TS Logical Channel 378 (PID value) and the corresponding TS Multiplex. This association 379 needs to permit a large number of active multicast groups, and 380 should minimise the processing load at the Receiver when filtering 381 and forwarding IP multicast packets. For example, schemes that may 382 be easily implemented in hardware would be beneficial, since these 383 may relieve the drivers and operating systems from discarding 384 unwanted multicast traffic. 386 There are specific issues concerning IPv4 and IPv6 multicast over 387 MPEG-2 Transmission Networks: 389 (i) Mapping IP multicast groups to the underlying MPEG-2 TS 390 Logical Channel (PID) and the MPEG-2 TS Multiplex. 392 (ii) Provide signalling information to allow a receiver to 393 locate an IP multicast flow within an MPEG-2 TS Multiplex. 395 (iii) Determining group membership (e.g. utilising IGMP/MLD). 397 Methods are required to identify the scope of an address when an 398 MPEG-2 transmission network supports several logical IP network and 399 carries groups within different multicast scopes. 401 Appropriate procedures need to specify the correct action when the 402 same multicast group is available on separate TS Logical Channels. 403 This could arise when different end hosts act as senders to 404 contribute IP packets with the same IP Group Destination Address in 405 the ASM address range. 407 Another different case arises when a Receiver could receive more 408 than one copy of the same packet (e.g. when packets are replicated 409 across different TS Logical Channels, or even different TS 410 Multiplexes, a method also known as Simulcasting [DVB-DAT]). In this 411 case, at the IP level, the host/router may be unaware of this 412 duplication and it needs to be detected by other means. 414 4. MPEG-2 Address Resolution 416 In this section, current MPEG-2 address resolution mechanisms are 417 reviewed. 419 4.1 Static configuration. 421 The static mapping option, where IP addresses or flows are 422 statically mapped to specific PIDs is the equivalent to signalling 423 "out-of-band". The application programmer, installing engineer, or 424 user receives the mapping via some outside means, not in the MPEG-2 425 TS. This is useful for testing, experimental networks, small 426 subnetworks and closed domains. 428 A single "well-known" PID is a specialisation of this. This scheme 429 is used by current DOCSIS cable modems [DOCSIS], where all IP 430 traffic is placed into the specified TS stream. Section or MAC 431 filtering may be used to differentiate subnetworks. 433 4.1.1 MPEG-2 Cable Networks 435 Cable networks use a different transmission schemes for downstream, 436 (headend to cable modem/STB) and upstream (cablemodem/STB to 437 headend) transmission. 439 The information is sent (on the downstream) to the STBs as 440 IP/Ethernet packets encapsulated in MPEG-2 TS Packets sent on a 441 single well-known TS Logical Channel (PID); there is no use of 442 inband tables. On the upstream, the common approach is to use 443 Ethernet framing, rather than IP/Ethernet over MPEG-2, although 444 other proprietary schemes also continue to be used. 446 Until the deployment of DOCSIS and EuroDOCSIS, most address 447 resolution schemes in cable networks for IP traffic was proprietary, 448 and did not usually employ a table-based address resolution method. 449 Proprietary methods continue to be used in some cases where STBs 450 require interaction. In this case, equipment at the headend may act 451 as gateways between the cablemodem/STB and the Internet. These 452 gateways receive L2 information and allocate an IP address. 454 DOCSIS utilises DHCP for IP client configuration. The Cable Modem 455 Terminal System (CMTS) provides a DHCP server that allocates IP 456 addresses to DOCSIS cable modems and STBs. The MPEG-2 Transmission 457 Network provides a L2 bridged network to the cable modem. This 458 usually acts as a DHCP relay for IP devices [RFC2131, RFC3256]. 459 Issues in deployment of IPv6 are described in [ID-V6OPS-DEPLOY]. 461 4.2 MPEG-2 Table-Based Address Resolution 463 The information about the set of MPEG-2 TS streams carried over a TS 464 Multiplex can be distributed via tables that are assigned a specific 465 and well-known set of PID values. This design requires access to and 466 processing of the SI Table information [ETSI-SI, ETSI-SI1]. This 467 scheme reflects the complexity of delivering and co-ordinating the 468 various TS associated with multimedia TV. A TS Multiplex may provide 469 AR information for IP services by integrating additional information 470 into the existing MPEG-2 tables or by transmitting additional SI 471 Tables specific to the IP service. 473 Examples of MPEG-2 Table usage to allow an MPEG-2 Receiver to 474 identify the appropriate PID and multiplex associated with a 475 specific IP address include: 477 (i) IP/MAC Notification Table (INT) in the DVB Data standard 478 [ETSI-DAT]. This provides uni-directional address resolution of 479 IPv4/IPv6 multicast addresses to MPEG-2 TS. 481 (ii) Application Information Table (AIT) in the Multimedia 482 Home Platform (MHP) specifications [ETSI-MHP]. 484 (iii)Multicast Mapping Table (MMT) an MPEG-2 Table employed by some 485 DVB-RCS systems to provide uni-directional address resolution 486 of IPv4 multicast addresses to MPEG-2 TS. 488 The MMT and AIT are used for specific applications. The INT [DVB- 489 DAT] is a more general DVB standard, that supports MAC, IPv4, and 490 IPv6 AR when used in combination with the other MPEG-2 tables. 492 4.2.1 IP/MAC Notification Table (INT) and its usage 494 The INT provides a mechanism for carrying information about the 495 location of IP/L2 flows within a DVB network. The INT defines the 496 concept of a Platform_ID, which may identify the addressing scope 497 for a set of IP/L2 streams and/or Receivers. A Platform may span 498 several transport streams within one or multiple DVB multiplexes and 499 represents a single IP network with a harmonized address space (i.e. 500 addressing scope). This allows for the coexistence of several non- 501 harmonized IP/MAC address spaces on the same DVB network. 503 The INT allows both fully-specified IP addresses and prefix matching 504 to reduce the size of table (and hence enhance signalling 505 efficiency). An IPv4/IPv6 "subnet mask" may be given in full form or 506 in slash notation (e.g. /127). 508 IP multicast addresses can be specified with or without a source 509 (address or range), although if a source address is specified, then 510 only the slash notation may be used for prefixes. 512 In addition to identification and security descriptors, the 513 following descriptors are defined for address binding in INT tables: 515 (i) target_MAC_address_descriptor: The descriptor used to 516 describe a single or set of MAC addresses (and their mask). 518 (ii) target_MAC_address_range_descriptor: May be used to set 519 filters. 521 (iii) target_IP_address_descriptor: The descriptor describing a 522 single or set of IPv4 unicast or multicast addresses (and 523 their mask). 525 (iv) target_IP_slash_descriptor: Allows definition and announcement 526 of an IPv4 prefix. 528 (v) target_IP_source_slash_descriptor: Uses source and destination 529 addresses to target a single or set of systems. 531 (vi) IP/MAC stream_location_descriptor: This descriptor locates an 532 IP/MAC stream in a DVB network. 534 The following descriptors provide corresponding functions for IPv6 535 addresses: 537 target_IPv6_address_descriptor 538 target_IPv6_slash_descriptor 539 and target_IPv6_source_slash_descriptor 541 The ISP_access_mode_descriptor allows specification of a second 542 address descriptor to access an ISP via an alternative non-DVB 543 (possibly non-IP) network. 545 The INT provides a set of descriptors to specify addressing in a DVB 546 network. One key benefit is that the approach follows the MPEG-2 547 signaling methods and is integrated with the other signalling 548 information. This allows the INT to operate in the presence of 549 (re)multiplexors [ipdvb-arch] and refer to PID values that are 550 carried within a number of different TS Multiplexes. This makes it 551 well-suited to a Broadcast TV Scenario [ipdvb-arch]. 553 The principle drawbacks are that while the INT, there is a need for 554 a Gateway to introduce associated PSI/SI MPEG-2 control information. 555 This control information also needs to be processed at the receiver 556 below the IP layer, and the position of this processing within the 557 protocol stack makes it hard to associate the results with IP 558 Policy, management and security functions. The use of centralized 559 management prevents the implementation of a more dynamic scheme. The 560 method is currently defined only for Multi-Protocol Encapsulation 561 (MPE) and would need extension to support other schemes. 563 4.2.2 Multicast Mapping Table (MMT) and its usage 565 The Multicast Mapping Table (MMT) is an MPEG-2 level control table 566 to that associates a set of multicast addresses with the 567 corresponding PID values. This table allows a DVB-RCS Forward Link 568 Subsystem (FLSS) to specify the mapping of IPv4 addresses to PID 569 values within a specific TS Multiplex. Receivers (DVB-RCS Return 570 Channel Satellite Terminals, RCSTs) may use this table to determine 571 the PID values associated with an IP multicast flow that it requires 572 to receive. The MMT is not currently a part of the DVB-RCS 573 specification. 575 4.2.3 Application Information Table (AIT) and its usage 577 The DVB Multimedia Home Platform (MHP) specification does not define 578 a specific AR function. However, the MHP Standard specifies an 579 Application Information Table (AIT) that allows MHP Receivers to 580 receive a variety of control information. The AIT uses a DSMCC 581 format table providing information about data broadcasts, the 582 required activation state of applications carried by a broadcast 583 stream, etc. This information allows a broadcaster to request that a 584 Receiver change the activation state of an application, and to 585 direct applications to receive specific multicast packet flows 586 (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a 587 specific function, but as a part of a wider configuration and 588 control function. 590 4.2.4 Comparison of SI/PSI table approaches 592 The MPEG-2 methods based on SI/PSI meet the specified requirements 593 of the groups that created them and all have their strength: the 594 INT in terms of flexibility and extensibility, the MMT in its 595 simplicity, the AIT in its extensibility. However, they exhibit 596 scalability constraints, encourage the development of technology 597 specific solutions and do not fully adopt IP-centric approaches that 598 would enable easier use of the MPEG-2 bearer as a link technology 599 within the wider Internet. 601 4.3 IP-based resolution of TS Logical Channels 603 As MPEG-2 transmission networks evolve to become multiservice 604 networks, the use of IP protocols is becoming more prevalent. 605 Most MPEG-2 networks now use some IP protocols for operations, 606 control and data delivery, transmission using IP packets could 607 also be used for address resolution. The advantages of using a 608 IP-based address resolution for TS streams include: 610 (i) Simplicity: 611 The AR mechanism does not require interpretation of Layer 2 612 tables; this is an advantage especially in the growing market 613 share for home network and audio video networked entities. 615 (ii) Uniformity: 616 An IP-based protocol can provide a common method across 617 different network scenarios for IP/MAC address mappings to TS 618 Logical Channels (PID Values). 620 (iii) Extensibility: 621 IP-based AR mechanisms allow an independent evolution of the AR 622 protocol. This includes dynamic methods to request address 623 resolution and the ability to include other L2 information 624 (e.g. Encryption keys). 626 (iv) Integration 627 The information exchanged by IP-based AR protocols can easily 628 be integrated as a a part of the IP network layer, simplifying 629 support for AAA, policy, OAM, mobility, configuration control, 630 etc. that combine AR with security. 632 Drawbacks of an IP-based method include: 634 One drawback of IP-based AR is that this method can not operate 635 over an MPEG-2 Transmission Network that uses remultiplexors 636 [ipdvb-arch] to modify the PID values of the TS Logical 637 Channels during the multiplexing operation. This makes the 638 method unsuitable for use in deployed broadcast TV networks 639 [ipdvb-arch]. 641 IP-based methods can also introduce concerns about the 642 integrity of the information and authentication of the sender 643 [ipdvb-arch] (These concerns are also applicable to MPEG-2 644 table methods, but in this case the information is confined to 645 the L2 network, or parts of the network where gateway devices 646 isolate the MPEG devices from the larger Internet creating 647 virtual MPEG2 private networks.) IP-based solutions should 648 therefore implement security mechanisms that may be used to 649 authenticate the sender and verify the integrity of the AR 650 information, as a part of a larger security framework. 652 4.3.1 IP-based multicast resolution of TS Logical Channels 654 AR resolution must also be performed to associate the IP multicast 655 Group Destination Address with an MPEG-2 layer TS Logical Channel 656 (PID) and TS Multiplex. Solutions have been described in 4.2 to 657 perform this below the IP layer using MPEG-2 Tables. Such methods 658 currently perform a direct mapping (where a single address or set of 659 addresses are associated with a specific PID value). 661 There is an opportunity to define an IP-level method that could use 662 an IP multicast protocol over a well-known IP multicast address. 663 Scalability is an important feature of any multicast AR protocol, 664 methods that employ prefix matching (e.g. where a range of 665 source/destination addresses are matched to a single entry are 666 desirable), but so also are methods that allow a range of addresses 667 to mapped to a set of TS Logical Channels (similar to the mapping of 668 IP Group Destination Addresses to Ethernet MAC addresses). 670 5. Mapping IP addresses to NPA/MAC addresses 672 This section reviews IETF protocols that may be used to assign and 673 manage the mapping of IP addresses to/from NPA/MAC addresses. 675 IP Encapsulation Gateways may require AR information to select an 676 appropriate MAC/NPA address in the SNDU header [ipdvb-arch] (see 677 also section 6). The information to complete this header may be 678 taken directly from a neighbour/arp cache, or may require the 679 Gateway to retrieve the information using an AR protocol. The way in 680 which this information is collected will depend upon whether the 681 Gateway functions as a Router (at L3) or a Bridge (at L2). 683 Two IETF-defined protocols for mapping IP addresses to NPA/MAC 684 addresses are ARP [RFC-ARP] and NDP [RFC-ND] for IPv4 and IPv6 685 respectively. Both protocols are normally used in a bi-directional 686 mode, although both also permit unsolicited transmission of 687 mappings. The mapping defined in [RFC2464] may result in use of a 688 large number of L2 MAC addresses. 690 ARP requires support for L2 broadcast packets. 692 << inputs requested on ARP scalability to large receiver groups >> 694 << inputs requested on ARP security for wireless networks >> 696 << inputs requested on ARP scoping when supporting multiple ISPs >> 698 The NDP uses a set of IP multicast addresses. In large networks, 699 many multicast addresses are likely to be used, although little 700 traffic is likely to be sent in each group. The AR multicast 701 mechanism therefore needs to be able to support this in a scalable 702 manner (see section XXX). 704 << inputs requested on NDP scalability to large receiver groups >> 706 << inputs requested on NDP security for wireless networks >> 708 << inputs requested on NDP scoping when supporting multiple ISPs >> 710 5.1 Uni-directional links supporting uni-directional connectivity 712 Most MPEG-2 Transmission Networks provide a Uni-Directional 713 broadcast link (UDL), with no return path. Such links may be used 714 for unicast applications that do not require a return path (e.g. 715 based on UDP), but are more commonly used for IP multicast content 716 distribution. 718 ,-----. 719 MPEG-2 uplink /MPEG-2 \ 720 *##################( Network ) 721 # \ / 722 +----*------+ `--.--' 723 | Network | | 724 | Provider + v MPEG-2 downlink 725 +-----------+ | 726 +-----v------+ 727 | MPEG-2 | 728 | Receiver | 729 +------------+ 731 Figure XX: Uni-directional connectivity 733 Although ARP and NDP may both operate in an unsolicited/promiscuous 734 mode where they advertise information to the remote nodes, this does 735 not provide an appropriate method to resolve the remote 736 (destination) address in a uni-directional environment. To perform 737 this task, these protocols require bi-directional L2/L3 738 connectivity. 740 << inputs required on receiver address assignment in this case >> 742 5.2 Uni-directional links with bi-directional connectivity 744 Bi-directional connectivity may be realised using a pair of uni- 745 directional in combination with another network path. Common 746 combinations are a Feed link using MPEG-2 satellite transmission and 747 a return link using terrestrial network infrastructure. This 748 topology is often known as a Hybrid network, and has asymmetric 749 network routing. It also often exhibits asymmetric network capacity 750 [RFC-ASYM]. 752 ,-----. 753 MPEG-2 uplink /MPEG-2 \ 754 *##################( Network ) 755 # \ / 756 +----*------+ `--.--' 757 | Network | | 758 | Provider +-<-+ v MPEG-2 downlink 759 +-----------+ | | 760 | +-----v------+ 761 +--<<--+ MPEG-2 | 762 uplink | Receiver | 763 +------------+ 765 Figure XX: Bi-directional connectivity 767 The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be 768 used to overcome the routing issues associated with asymmetric 769 routing. UDLR provides a L2 tunnelling mechanism that emulates a bi- 770 directional broadcast link at L2. The uni-directional routing is 771 hidden from IP and upper layer protocols. 773 This section introduces how to use UDLR link layer tunnelling 774 mechanisms to use ARP and ND on Uni-Directional DVB links. 776 <<< Will be completed later, inputs required from WG >>> 778 5.3 Bi-directional links 780 Bi-directional IP networks can be and are constructed by a 781 combination of two MPEG-2 transmission links. The combined link 782 functions as a full duplex interface. Examples of this use include 783 two-way DVB-S satellite links and the DVB-RCS system. 785 <<< text on DHCP, L2TP, PPoE, etc to be added by 786 other volunteers >>> 788 5.4 IP Multicast AR 790 This section describes the case where the destination network layer 791 address is an IP multicast Group Destination Address. 793 In MPE [DVB-DAT], the mapping of IP multicast addresses to MAC/NPA 794 addresses follows normal practice for IEEE MAC Addresses when using 795 IPv4 and IPv6. (A variant of DVB (DVB-H) uses a modified MAC header 796 [DVB_DAT]). 798 In ULE [ID-IPDVB-ULE], the L2 NPA address is optional, and is not 799 necessarily required when the Receiver is able to perform efficient 800 L3 multicast address filtering. When present, it follows the mapping 801 of MPE and many other L2 link technologies. 803 6. Link Layer Support 805 This section considers layer 2 support for address resolution. It 806 considers two issues that need to be considered. One is the code- 807 point to be used at L2 and the other is the efficiency of 808 encapsulation for transmission to utilise the AR method. The table 809 below summarises the options for both MPE and ULE encapsulations. 811 +-------------------------------+--------+----------------------+ 812 | | PDU |L2 Frame Header Fields| 813 | L2 Encapsulation |overhead+----------------------+ 814 | |[bytes] |src mac|dst mac| type | 815 +-------------------------------+--------+-------+-------+------+ 816 |6.1 ULE without dst MAC address| 8 | - | - | x | 817 |6.2 ULE with dst MAC address | 14 | - | x | x | 818 |6.3 MPE without LLC/SNAP | 16 | - | x | - | 819 |6.4 MPE with LLC/SNAP | 24 | - | x | x | 820 |6.5 ULE with Bridging extension| 22 | x | x | x | 821 |6.6 ULE with Bridging & NPA | 28 | x | x | x | 822 |6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x | 823 +-------------------------------+--------+-------+-------+------+ 825 Table of L2 support and overhead (x=supported, -=not supported) 827 The remainder of the section describes IETF-specified AR methods for 828 use with these encapsulation formats. 830 6.1 ULE without a destination MAC/NPA address (D=1) 832 The ULE encapsulation supports a mode (D=1) where the NPA/MAC 833 address is not present in the encapsulated frame. This mode may be 834 used with both IPv4 and IPv6. When this mode is used, the Receiver 835 is expected to perform network-layer filtering of packets based on 836 their IP destination address. Encapsulation Gateways must ensure 837 that packets are associated with a TS Logical Channel (PID value) 838 that uniquely identifies the intended recipient [IP-IPDVB-ULE]. This 839 requires careful consideration of the network topology when used as 840 a link between IP routers (a simple case where this is permitted is 841 the connection of stub networks). 843 Since there is no MAC/NPA address in the SNDU, ARP and NDP are not 844 required. 846 Note, since IPv6 systems can (and usually do) automatically 847 configure their IPv6 network address based upon a local MAC address, 848 the IP driver at the Receiver may still need to access the MAC/NPA 849 address of the receiving interface. 851 6.2 ULE with a destination NPA/MAC address (D=0) 853 The IPv4 Address Resolution Protocol (ARP) [RFC826] uses an IANA- 854 assigned EtherType and may be used over a link that supports ULE 855 [IP-IPDVB-ULE]. Although no MAC source address is present in the 856 SNDU, the protocol still communicates the source MAC address in the 857 ARP record payload of any query messages that it generates. 859 The ND protocol of IPv6 [RFC2461] may be used.NDP does not require 860 specification of a MAC source address, although this is required for 861 a node to participate in Duplicate Address Detection (DAD). 863 << More info on use of ND is required, also on usage of DAD and 864 SEND>> 866 6.3 MPE without LLC/SNAP Encapsulation 868 This is the default (and sometimes only) mode specified by most MPE 869 Encapsulation Gateways. 871 MPE does not provide an IANA-assigned EtherType and therefore can 872 not support the Address Resolution Protocol (ARP) [RFC826]. 874 IPv6 is not supported in this encapsulation format, and therefore it 875 is not appropriate to consider the NDP. 877 6.4 MPE with LLC/SNAP Encapsulation 879 The LLC/SNAP format of MPE provides an IANA-assigned EtherType and 880 therefore may support the Address Resolution Protocol (ARP) 881 [RFC826]. There is no specification to define how this is performed. 882 No MAC source address is present in the SNDU, although the protocol 883 still communicates the source MAC address in the ARP record payload 884 of any query messages that it generates. 886 The ND protocol of IPv6 [RFC2461] may be used with The LLC/SNAP 887 format of MPE. NDP does not require specification of a MAC source 888 address, although this is required for a node to participate in 889 Duplicate Address Detection (DAD). 891 << More info on use of ND is required, also on usage of DAD and 892 SEND>> 894 6.5 ULE with Bridging Header Extension (D=1) 896 The ULE encapsulation supports a bridging extension header that 897 supplies both a source and destination MAC address. This can be 898 used without an NPA address (D=1). When no other Extension Headers 899 are present, the MAC destination address has the same position in 900 the ULE SNDU as that used for an NPA destination address. The 901 Receiver may optionally be configured so that MAC destination 902 address value is identical to the Receiver NPA address. 904 At the Encapsulation Gateway, the ULE NPA/MAC destination address is 905 determined by a L2 forwarding decision. Received frames may be 906 forwarded or may be addressed to the Receiver itself. As in other L2 907 LANs, the Receiver may choose to filter received frames based on a 908 configured MAC destination address filter. 910 ARP messages may be carried within a PDU that is bridged by this 911 encapsulation format. 913 The NDP messages may be carried within an IPv6 PDU that is bridged 914 by this encapsulation format. 916 6.6 ULE with Bridging Header Extension and NPA Address (D=0) 918 The combination of a NPA address (D=0) and a bridging extension 919 header are allowed in ULE. This SNDU format supplies both a source 920 and destination MAC address and a NPA destination address (i.e. 921 Receiver NPA/MAC address). 923 At the Encapsulation Gateway, the ULE NPA/MAC destination address is 924 determined by a L2 forwarding decision. Received frames may be 925 forwarded or may be addressed to the Receiver itself. As in other L2 926 LANs, the Receiver may choose to filter received frames based on a 927 configured MAC destination address filter. 929 An ARP message may be carried within a PDU that is bridged by this 930 encapsulation format. 932 An NDP message may be carried within an IPv6 PDU that is bridged by 933 this encapsulation format. 935 6.7 MPE+LLC/SNAP+Bridging 937 The LLC/SNAP format MPE frames may optionally support an IEEE 938 bridging header [LLC]. This header supplies both a source and 939 destination MAC address, at the expense of larger encapsulation 940 overhead. This format defines two MAC destination addresses, one 941 associated with the MPE SNDU (i.e. Receiver MAC address) and one 942 with the bridged MAC frame (i.e. the MAC address of the intended 943 recipient in the remote LAN). At the Encapsulation Gateway, the MPE 944 MAC destination address is determined by a L2 forwarding decision. 945 As in other L2 LANs, the Receiver may choose to filter received 946 frames based on a configured MAC destination address filter. 948 At the Encapsulation Gateway, the MPE MAC destination address is 949 determined by a L2 forwarding decision. Received frames may be 950 forwarded or may be addressed to the Receiver itself. As in other L2 951 LANs, the Receiver may choose to filter received frames based on a 952 configured MAC destination address filter. 954 An ARP message may be carried within a PDU that is bridged by this 955 encapsulation format. 957 An NDP message may be carried within an IPv6 PDU that is bridged by 958 this encapsulation format. The MPE MAC destination address is 959 determined by a L2 forwarding decision. 961 7. Conclusions 963 This document has described addressing and address resolution issues 964 concerning the use of IP protocols over MPEG-2 transmission 965 networks. A number of specific IETF protocols are discussed along 966 with their expected behaviour over MPEG-2 transmission networks and 967 recommendations for usage. 969 In current MPEG-2 networks, a static binding may be configured for 970 IP addresses and PIDs (as in some cable networks). This information 971 may also be provided by the Gateway/Multiplexor and carried in 972 tables (e.g. AIT in MHP, the IP Notification Table, INT, of DVB and 973 the DVB-RCS Multicast Mapping Table, MMT). This document has 974 reviewed the status of these current address resolution mechanisms 975 in MPEG-2 transmission networks, defined their usage and provided 976 information to identify what would be needed to improve their 977 support for IP protocols. 979 8. Security Considerations 981 The normal security issues relating to the use of wireless links for 982 transport Internet traffic should be considered. Readers are also 983 referred to the known security issues associated with ARP [RFC826] 984 and ND [RFC-ND]. 986 9. Acknowledgments 988 The authors wish to thank Rod Walsh, Jun Takei, Michael Mercurio and 989 the ipdvb WG members for their inputs. The authors would also like 990 to acknowledge the support of the European Space Agency. The authors 991 also thank Martin Stiemerling, for contributions of scenarios and 992 configuration, and Hidetaka Izumiyama for his contributions on UDLR 993 issues. 995 10. References 997 10.1 Normative References 999 [ETSI-DAT] EN 301 192, "Specifications for Data 1000 Broadcasting", v1.3.1, European Telecommunications Standards 1001 Institute (ETSI), May 2003. http://www.etsi/org/ 1003 [ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB); 1004 Multimedia Home Platform (MHP) Specification", v1.2.1, European 1005 Telecommunications Standards Institute (ETSI), June 2002. 1006 http://www.etsi/org/ 1008 [ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB); 1009 Specification for Service Information (SI) in DVB systems". 1011 [ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic 1012 coding of moving pictures and associated audio information -- Part 1013 6: Extensions for DSM-CC is a full software implementation", 1014 International Standards Organisation (ISO). 1016 [ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic 1017 coding of moving pictures and associated audio information -- Part 1018 1: Systems", International Standards Organisation (ISO), 2000. 1020 [RFC826] Plummer, D. "An Ethernet Address Resolution Protocol", 1021 RFC 826, IETF, November 1982. 1023 [RFC1112] Deering, S.E., "Host Extensions for IP Multicasting", 1024 RFC1112, (STD05), IETF. August 1989. 1026 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1027 Discovery for IP Version 6 (IPv6), RFC 2461, December 1998. 1029 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1030 Networks", RFC 2464, December 1998. 1032 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 1033 Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", 1034 RFC 3077, March 2001. 1036 10.2 Informative References 1038 [ATSC] A/53C, "ATSC Digital Television Standard", Advanced 1039 Television Systems Committee (ATSC), Doc. A/53C, 2004. 1041 [DOCSIS]>>> Missing Reference <<< 1043 [ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB); 1044 Allocation of Service Information (SI) codes for DVB systems". 1046 [ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D., 1047 Collini-Nocker, B., and H. Linder, "Architecture for IP transport 1048 over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt, 1049 February 2005, Work in Progress, IPDVB WG. 1051 [ID-IPDVB-ULE] Fairhurst, G., Collini-Nocker, B. "Ultra Lightweight 1052 Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 1053 Transport Stream", February 2005, Work in Progress, IPDVB WG. 1055 [ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C., 1056 "ISP IPv6 Deployment Scenarios in Broadband Access Networks" 1057 draft-ietf-v6ops-bb-deployment-scenarios-00.txt, Work in Progress, 1058 IPDVB WG 1060 [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable 1061 Service Interface Specifications) Device Class DHCP (Dynamic Host 1062 Configuration Protocol) Relay Agent Information Sub-option", RFC 1063 3256, April 2002. 1065 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1066 2131, March 1997. 1068 10.3 Un-cited references (to be used or removed in final edit): 1070 [RFC1122] B. Braden, ed., "Requirements for Internet Hosts - 1071 Communication Layers", RFC 1122. 1073 http://www.atsc.org/standards/Code_Point_Registry.pdf 1075 [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. 1076 Schulzrinne, "Protocol Requirements for Internet Media Guides", 1077 Internet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work 1078 in Progress, MMUSIC WG. 1080 [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television 1081 Systems Committee (ATSC), Doc. A/090, 2000. 1083 [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines 1084 for the ATSC Data Broadcast Standard", Advanced Television Systems 1085 Committee (ATSC),Doc. A/91, 2001. 1087 [ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data 1088 Broadcast", Advanced Television Systems Committee (ATSC), 1089 Doc. A/92, 2002. 1091 [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television 1092 Standard", Advanced Television Systems Committee (ATSC), 1093 Doc. A/54A, 2003. 1095 [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for 1096 Terrestrial Broadcast and Cable", Advanced Television Systems 1097 Committee (ATSC), Doc. A/65B, 2003. 1099 [ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.1, 1100 European Telecommunications Standards Institute (ETSI), May 2003. 1101 http://www.etsi/org/ 1103 11. Authors' Addresses 1105 Godred Fairhurst 1106 Department of Engineering 1107 University of Aberdeen 1108 Aberdeen, AB24 3UE 1109 UK 1110 Email: gorry@erg.abdn.ac.uk 1111 Web: http://www.erg.abdn.ac.uk/users/gorry 1113 Marie-Jose Montpetit 1114 MJMontpetit.com 1115 Email: marie@mjmontpetit.com 1117 Hidetaka Izumiyama 1118 President CEO, Wishnet Inc. 1119 5-15-5-001 Shirokanedai, Minato-ku 1120 Tokyo, 108-0071, Japan 1121 Email: izu@wishnet.co.jp 1122 12. IPR Notices 1124 12.1 Intellectual Property Statement 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed 1128 to pertain to the implementation or use of the technology described 1129 in this document or the extent to which any license under such 1130 rights might or might not be available; nor does it represent that 1131 it has made any independent effort to identify any such rights. 1132 Information on the procedures with respect to rights in RFC 1133 documents can be found in BCP 78 and BCP 79. 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use 1138 of such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository 1140 at http://www.ietf.org/ipr. 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at ietf- 1146 ipr@ietf.org. 1148 12.2 Disclaimer of Validity 1150 This document and the information contained herein are provided on 1151 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1152 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1153 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1154 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1155 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1156 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1158 13. Copyright Statement 1160 Copyright (C) The Internet Society (2004). This document is 1161 subject to the rights, licenses and restrictions contained in 1162 BCP 78, and except as set forth therein, the authors retain all 1163 their rights. 1165 14. IANA Considerations 1167 NOT KNOWN AT THIS TIME. 1169 APPENDICES 1171 [>>> NOTE to RFC Editor: Please remove this appendix prior to 1172 publication] 1174 APPENDIX A: Document History 1176 -00 This draft is intended as a study item for proposed future 1177 work by the IETF in this area. 1178 -01 Review of initial content, major edit and refinement of 1179 concepts 1180 -02 fairly important review; took out all new protocol reference; 1181 added one author; added contribution on real implementation 1182 -02 Added content to respond to 61st IETF comments; 1183 refined ID goals; rewrote section 4.2 and 4.3; added cable 1184 information. 1185 -03 Major reorganise to align with Charter, and clearly identify 1186 IP issues. 1187 -04 restructured the draft (major rewrite) and added discussion of 1188 arp and ND related to specific cases for use. 1190 [>>> NOTE to RFC Editor: End of appendix] 1191 APPENDIX B: Candidate IP-based L2 AR Protocols 1193 This appendix contains a list of candidate protocols for "above IP" 1194 AR. None of these protocols currently support the AR methods 1195 required for MPEG-2 Transmission Networks. Specifically they do not 1196 all support: 1198 (i) Resolution of Addresses to TS Logical Channels 1199 (ii) Resolution of multiple addresses in a single AR update message 1200 (table-based). 1201 (iii) Multicast transport. 1203 Candidate protocols include: 1205 ARP 1206 - IPv4 only. 1207 - No table support 1208 - Support for versioning within current implementations not clear. 1209 - Broadcast mode has drawbacks. 1210 - No obvious support for scoping to multiple addressing domains. 1212 ND 1213 - IPv6 only. 1214 - No table support 1215 - Use multicast address. 1216 - No obvious support for scoping to multiple addressing domains. 1218 DTCP [RFC3077] 1219 - IPv4 and IPv6. 1220 - Table support seems natural. 1221 - Uses multicast address. 1222 - Need to consider scoping for multiple addressing domains. 1223 - Not really an IP AR protocol 1224 - Already used on some (UDLR) links - and this new use seems 1225 complementary. 1227 AR/IP 1228 - IPv4 and IPv6. 1229 - Based on UDP or at network-layer. 1230 - Could use multicast address. 1231 - Table support possible. 1232 - New protocol format. 1233 - Could add scoping for multiple addressing domains. 1235 XML/foo/IP 1236 - IPv4 and IPv6. 1237 - Based on UDP or at network-layer or an XML transport (which?). 1238 - Could use multicast address. 1239 - Table support seems natural. 1240 - New protocol format. 1241 - Could add scoping for multiple addressing domains. 1242 - Extensible/flexible to other configuration data (if required). 1244 - Compression of XML required to achieve efficiency comparable with 1245 other methods. 1247 <<<<