idnits 2.17.1 draft-ietf-mext-nemo-ro-automotive-req-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1099. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 829: '...establishment procedure, MUST have the...' RFC 2119 keyword, line 831: '... for the switching to RO MUST at least...' RFC 2119 keyword, line 833: '...ished. Policies MAY change dynamicall...' RFC 2119 keyword, line 849: '...o The RO scheme MUST permit the recei...' RFC 2119 keyword, line 852: '...o The RO scheme MUST ensure that only...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3775' is defined on line 957, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-04) exists of draft-ietf-mext-aero-reqs-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT R. Baldessari 3 Internet-Draft NEC Europe 4 Intended status: Informational T. Ernst 5 Expires: January 15, 2009 INRIA 6 A. Festag 7 NEC Germany 8 M. Lenardi 9 Hitachi Europe 10 July 14, 2008 12 Automotive Industry Requirements for NEMO Route Optimization 13 draft-ietf-mext-nemo-ro-automotive-req-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 15, 2009. 40 Abstract 42 This document specifies requirements for NEMO Route Optimization 43 techniques as identified by the automotive industry. Requirements 44 are gathered from the Car2Car Communication Consortium and ISO 45 Technical Committee 204 Working Group 16 (CALM). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. NEMO Automotive Deployments . . . . . . . . . . . . . . . . . 5 52 3.1. Car2Car Communication Consortium . . . . . . . . . . . . . 5 53 3.1.1. System and Protocol Architecture . . . . . . . . . . . 6 54 3.1.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 10 55 3.1.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 11 56 3.2. ISO TC204 WG 16 (CALM) . . . . . . . . . . . . . . . . . . 12 57 3.2.1. System and Protocol Architecture . . . . . . . . . . . 12 58 3.2.2. IPv6 Deployment . . . . . . . . . . . . . . . . . . . 16 59 3.2.3. Scope of NEMO . . . . . . . . . . . . . . . . . . . . 17 60 4. NEMO Example Use Cases . . . . . . . . . . . . . . . . . . . . 17 61 4.1. Notification Services . . . . . . . . . . . . . . . . . . 17 62 4.2. Peer-to-peer Applications . . . . . . . . . . . . . . . . 17 63 4.3. Upload and Download Services . . . . . . . . . . . . . . . 18 64 4.4. Vehicles Monitoring . . . . . . . . . . . . . . . . . . . 18 65 4.5. Infotainment Applications . . . . . . . . . . . . . . . . 18 66 4.6. Navigation Services . . . . . . . . . . . . . . . . . . . 18 67 5. NEMO Route Optimization Scenarios . . . . . . . . . . . . . . 18 68 6. NEMO Route Optimization Requirements . . . . . . . . . . . . . 19 69 6.1. Req 1 - Separability . . . . . . . . . . . . . . . . . . . 19 70 6.2. Req 2 - RO Security . . . . . . . . . . . . . . . . . . . 20 71 6.3. Req 3 - Binding Privacy Protection . . . . . . . . . . . . 20 72 6.4. Req 4 - Multihoming . . . . . . . . . . . . . . . . . . . 20 73 6.5. Req 5 - Minimum Signaling . . . . . . . . . . . . . . . . 21 74 6.6. Req 6 - Switching HA . . . . . . . . . . . . . . . . . . . 21 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 82 Intellectual Property and Copyright Statements . . . . . . . . . . 25 84 1. Introduction 86 NEMO Basic Support [RFC3963] defines a protocol that provides IPv6 87 mobility support for entire moving networks, where all data packets 88 go through the IPv6-in-IPv6 tunnel established between the Mobile 89 Router (MR) and the Home Agent (HA). As already pointed out in 90 various documents ([RFC4888], [RFC4889] and 91 [I-D.ietf-mext-aero-reqs]) this can have severe consequences on the 92 communication performances, as it causes data packets to follow a 93 path that can be very far from optimal and requires a double IPv6 94 header for every packet exchanged with a Correspondent Node (CN) in 95 the Internet. Compared with a communication that uses the ideal 96 packet routing and the normal IPv6 header size, these factors result 97 in an increased delay and a reduced throughput, plus indirect 98 consequences like increased packet fragmentation and overall less 99 efficient usage of resources. 101 Various projects and consortia involving the automotive industry are 102 considering NEMO as part of their protocol stack for the provisioning 103 of session continuity and global reachability. Nevertheless, the 104 lack of standardized Route Optimization (RO) techniques allowing data 105 packets to be exchanged directly between vehicles or between vehicles 106 and hosts in the Internet is regarded as an obstacle for the actual 107 deployment of this protocol. As the definition of a general NEMO 108 Route Optimization technique is highly complex, it appears more 109 reasonable to address specific deployment requirements and design 110 more tailored, less complex schemes for Route Optimization. 112 This document gathers requirements from two bodies that are committed 113 in deploying vehicular communications including NEMO as part of their 114 protocol stacks. 116 o The Car2Car Communication Consortium [c2ccc-web] is an industry 117 consortium of car manufacturers and electronics suppliers 118 operating in Europe. Its mission is to establish an open European 119 industry standard for vehicular communications based on wireless 120 LAN technology. Its approach consists in considering vehicles as 121 a Vehicular ad hoc Network (VANET), where cars are equipped with 122 short-range communication devices that operate at frequencies 123 dedicated to safety and non-safety vehicular applications. 125 o ISO TC 204 WG 16 (CALM): ISO (International Standard Organization) 126 runs a number of Technical Committees. Members are nations and 127 offical participants represent their country. TC 204 is devoted 128 to Intelligent Transport Systems (ITS) and comprises a number of 129 Working Groups (16, but 12 still in operation). ISO TC 204 WG 16 130 is working on "Wide Area Communications Protocols and Interfaces" 131 and was established in year 2000. It is specifying a protocol 132 architecture from the physical layer up to the application layer 133 and designed for all ITS types of communications (vehicle-vehicle, 134 vehicle-infrastructure, infrastrutcure-vehicle). Known as the 135 CALM architecture, the acronym was initially set to mean 136 "Communications Air-interface, Long and Medium range" but was 137 renamed in 2007 to "Communication Architecture for Land Mobile". 139 The document is organized as follows: Section 2 defines terminology. 140 Section 3 overviews the technical approaches adopted by the two 141 automotive bodies to deploy NEMO. Section 4 provides a non- 142 exhaustive list of use cases of NEMO in automotive applications. 143 Section 5 introduces the RO scenario and finally Section 6 lists the 144 requirements for NEMO RO. 146 2. Terminology 148 The following terms used in this document are defined in the Network 149 Mobility Support Terminology document [RFC4885]: 151 o Mobile Network 153 o Network Mobility (NEMO) 155 o Home Agent (HA) 157 o Home Address (HoA) 159 o Mobile Router (MR) 161 o Mobile Network Prefix (MNP) 163 o Mobile Network Node (MNN) 165 o Correspondent Router (CR) 167 o Correspondent Entity (CE) 169 o Egress Interface 171 o Ingress Interface 173 The following new terms are used in this document: 175 o On Board Unit (OBU): a device installed in vehicles, implementing 176 the communication protocols and algorithms and equipped with at 177 least 1) a short-range wireless network interface operating at 178 dedicated frequencies and 2) a wireless or wired network interface 179 where Application Units (AU) can be attached to. With respect to 180 the NEMO terminology, the OBU is the physical machine acting as 181 MR, 1) is used as egress interface and 2) as ingress. 183 o Application Unit (AU): a portable or built-in device connected 184 temporarily or permanently to the vehicle's OBU. It is assumed 185 that AUs support a standard TCP/IPv6 protocol stack. Devices 186 enhanced with Mobile IPv6, like hand-held user devices, also fall 187 into the definition of Application Unit. With respect to the NEMO 188 terminology, an AU is a generic MNN. 190 o Road Side Unit (RSU): a device installed along roadsides 191 implementing automotive communication protocols and algorithms. 192 RSUs can either be isolated or connected to a network 193 infrastructure. In the latter case, RSUs are attachment points 194 either acting themselves as IPv6 access routers or as bridges 195 directly connected to an access router. 197 o In-vehicle network: the wireless or wired network placed in a 198 vehicle and composed by (potentially) several AUs and one OBU. 200 o Vehicle-to-Vehicle (V2V) Communication Mode: a generic 201 communication mode in which data packets are exchanged between two 202 vehicles, either directly or by means of multi-hop routing, 203 without involving any node in the infrastructure. 205 o Vehicle-to-Infrastructure (V2I) Communication Mode: a generic 206 communication mode in which data packets sent or received by a 207 vehicle traverse a network infrastructure. 209 3. NEMO Automotive Deployments 211 3.1. Car2Car Communication Consortium 213 The Car2Car Communication Consortium (C2C-CC [c2ccc-web]) is an 214 industry consortium of car manufacturers and electronics suppliers 215 that focuses on the definition of an European standard for vehicular 216 communication protocols. The Consortium gathers results from 217 research projects and aims at harmonizing their efforts. For the 218 standardization activity, the C2C-CC operates in cooperation with the 219 newly established ETSI TC ITS (Technical Committee Intelligent 220 Transportation System). 222 The consortium's Manifesto [c2ccc-manifesto] gives an overview of the 223 system and protocol architecture, as well as of the applications on 224 which the Consortium has agreed so far. In essence, this document 225 defines a C2C-C protocol stack that offers specialized 226 functionalities and interfaces to (primarily) safety-oriented 227 applications and relies as a communication technology on a modified 228 version of IEEE 802.11p [IEEE.802-11p-d3-0]. This protocol stack is 229 placed beside a traditional TCP/IP stack, based on IP version 6, 230 which is used mainly for non-safety applications or potentially by 231 any application that is not subject to strict delivery requirements, 232 including Internet-based applications. The interaction between these 233 stacks is currently discussed and briefly overviewed in this 234 document. 236 3.1.1. System and Protocol Architecture 238 The current draft reference architecture of the C2C communication 239 system is shown in Figure 1. 241 | Internet | 242 | | 243 +---+-----------------+-+ 244 | | 245 Access +--+-+ +--+-+ Access 246 Router | AR | | AR | Router 247 +--+-+ +--+-+ 248 | | 249 --+---+--- --+---+-- 250 | | 251 Road Side +--+--+ +--+--+ Public 252 Unit | RSU | | PHS | Hot Spot 253 +---+-+ +---+-+ 254 | | 255 /\ /\ 257 \_ \_ 258 \_ \_ 259 \ \ 261 Mandatory \/ 262 Mod IEEE 802.11p | __ \/ Optional IEEE 263 Interface +---+--+ \__ \/ | 802.11a/b/g 264 | OBU1 | | | Interface 265 +--+---+ +-+-----+---+ 266 Vehicle1 | | OBU2 | On-Board 267 -+---+-+- +--+--------+ Unit 268 | | | Vehicle2 269 Application +--+-+ +-+--+ --+--+-- 270 Units | AU | | AU | | 271 +----+ +----+ +-+--+ 272 | AU | 273 +----+ 275 Figure 1: C2C-CC Reference Architecture 277 Vehicles are equipped with networks logically composed of an OBU and 278 potentially multiple AUs. An AU is typically a dedicated device that 279 executes a single or a set of applications and utilizes the OBU 280 communication capabilities. An AU can be an integrated part of a 281 vehicle and be permanently connected to an OBU. It can also be a 282 portable device such as laptop, PDA or game pad that can dynamically 283 attach to (and detach from) an OBU. AU and OBU are usually connected 284 with wired connection, but the connection can also be wireless, such 285 as Bluetooth. The distinction between AU and OBU is logical, they 286 can also reside in a single physical unit. 288 Vehicles' OBUs and stationary units along the road, termed road-side 289 units (RSUs), form a self-organizing network. An OBU is at least 290 equipped with a (short range) wireless communication device based on 291 draft standard IEEE 802.11p [IEEE.802-11p-d3-0] (adapted to European 292 conditions and with specific C2C-C extensions) primarily dedicated 293 for road safety, and potentially with other optional communication 294 devices. OBUs directly communicate if wireless connectivity exist 295 among them. In case of no direct connectivity, multi-hop 296 communication is used, where data is forwarded from one OBU to 297 another, until it reaches its destination. For example in Figure 1, 298 RSU and OBU1 have direct connectivity, whereas OBU2 is out of RSU 299 radio coverage but can communicate with it through multi-hop routing. 301 The primary role of an RSU is improvement of road safety. RSUs have 302 two possible configuration modes: as isolated nodes, they execute 303 applications and/or extend the coverage of the ad hoc network 304 implementing routing functionalities. As attachment point connected 305 to an infrastructure network, RSUs distribute information originated 306 in the infrastructure and offer connectivity to the vehicles. As 307 result, for example, the latter configuration allows AUs registered 308 with an OBU to communicate with any host located in the Internet, 309 when at least one RSU connected to a network infrastructure is 310 available. 312 An OBU may also be equipped with alternative wireless technologies 313 for both, safety and non-safety. For example, an OBU may also 314 communicate with Internet nodes or servers via public wireless LAN 315 hot spots (PHS) operated individually or by wireless Internet service 316 providers. While RSUs for Internet access are typically set up with 317 a controlled process by a C2C-C key stake holder, such as road 318 administrators or other public authorities, public hot spots are 319 usually set up in a less controlled environment. These two types of 320 infrastructure access, RSU and PHS, also correspond to different 321 applications types. Other communication technologies, such as wide 322 coverage/cellular networks (e.g. UMTS, GPRS) do not fall in the 323 scope of the C2C-CC activity. Nevertheless, the C2C-CC aims at 324 guaranteeing future system extensibility and interoperability with 325 different technologies. 327 The protocol stack currently considered by the C2C-CC for OBUs is 328 depicted in Figure 2. 330 +--------------------+------------------+ 331 | | | 332 | C2C-CC | IP-based | 333 | Applications | Applications | 334 | | | 335 +--------------------+------------------+ 336 | | TCP/UDP/... | 337 | C2C-CC Transport +------------------+ 338 | | IPv6 | 339 +--------------------+---------+ | 340 | | | 341 | C2C-CC Network | | 342 | | | 343 +--------------------+---------+--------+ 344 | Modified | Standard WLAN | 345 | IEEE 802.11p | IEEE 802.11a/b/g | 346 +--------------------+------------------+ 348 Figure 2: OBU Protocol Stack 350 Protocol blocks are explained in the following list: 352 o Modified IEEE 802.11p: this block represents MAC and PHY layers of 353 a wireless technology based upon current draft standard IEEE 354 802.11p [IEEE.802-11p-d3-0] but modified for usage in Europe. In 355 Europe, allocation of dedicated frequencies around 5.9 GHz for 356 safety and non-safety applications is in progress. Expected 357 communication range in line of sight is at least 500m. This 358 network interface is mandatory. 360 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 361 provided by one ore more IEEE 802.11a/b/g network interfaces. 362 This network interface is optional but C2C-C Consortium encourages 363 its installation. 365 o C2C-CC Network: this block represents the network layer protocol 366 currently defined by the C2C-CC. The protocol provides secure ad 367 hoc routing and forwarding, as well as addressing, error handling, 368 packet sequencing, congestion control and information 369 dissemination. The specification of this protocol is currently 370 under discussion. Only the C2C-CC Network protocol can access the 371 Modified IEEE 802.11p network interface. The C2C-CC Network 372 protocol can also access the IEEE 802.11a/b/g interface. The 373 C2C-CC Network protocol offers an interface to the IPv6 protocol. 374 This interface allows IPv6 headers and payload to be encapsulated 375 into C2C-CC Network datagrams and sent over the Modified IEEE 376 802.11p or IEEE 802.11a/b/g network interface. The specification 377 of this interface is currently under discussion. A primary goal 378 of the C2C-CC Network layer is to provide geographic routing and 379 addressing functionalities for cooperative safety applications. 380 Through the mentioned interface to the IPv6 protocol, these 381 functionalities are also available for IP-based applications. 383 o C2C-CC Transport: this block represents the transport layer 384 protocol that is currently being defined by the C2C-CC. This 385 protocol provides a selected set of traditional transport layer 386 functionalities (e.g. application data multiplexing/ 387 demultiplexing, connection establishment, reliability etc.). The 388 specification of this protocol is currently under discussion. 390 o C2C-CC Applications: this block represents the application layer 391 protocol currently defined by the C2C-CC and concerns Active 392 Safety and Traffic Efficiency Applications. 394 3.1.2. IPv6 Deployment 396 As described in Section 3.1.1, the C2C-CC includes IPv6 as mandatory 397 part of its specified protocol architecture. Currently, three 398 methods are discussed for transmission of IPv6 headers and their 399 payload: 401 o On the Modified IEEE 802.11p interface via the C2C-CC Network 402 layer: in this method, IPv6 packets are tunneled in C2C-CC Network 403 headers and sent using dedicated frequencies for inter-vehicle 404 communications. Since the C2C-CC Network layer provides ad hoc 405 routing, from the IPv6 layer perspective other nodes (OBUs and 406 RSUs) appear as attached to the same link. The broadcast domain 407 used for IPv6 multicast traffic is selected by the C2C-CC Network 408 layer on a geographical basis. The C2C-CC Network layer presents 409 Ethernet-like characteristics, so that [RFC2464] can be applied. 411 o On the IEEE 802.11a/b/g interface via the C2C-CC Network layer: in 412 this method, IPv6 headers are encapsulated into C2C-CC Network 413 headers and sent using license-free ISM frequency bands (wireless 414 LAN). Except the network interface, this method is equivalent to 415 the previous one. 417 o On the IEEE 802.11a/b/g interface directly: in this method, IPv6 418 headers are sent directly to the wireless LAN interface. 420 As a result, a C2C-CC OBU has at least two IPv6 network interfaces, a 421 real one (IEEE 802.11a/b/g) and a virtual one (tunnel over C2C-CC 422 Network layer). The following informational list briefly summarizes 423 some currently discussed design concepts: 425 o in order to avoid address resolution procedures, vehicles only use 426 IPv6 addresses with as host part an EUI-64 identifier derived from 427 the MAC address. Privacy issues described in [RFC3041] are 428 strongly alleviated through the use of temporary, changing MAC 429 addresses, which are assigned in a set to every vehicle; 431 o according to the current availability of infrastructure 432 connectivity, OBUs can use (at least) 2 types of globally routable 433 IPv6 addresses: an IPv6 address configured using standard IPv6 434 stateless address configuration from Router Advertisements sent by 435 RSUs connected to a network infrastructure and an IPv6 address 436 configured from a prefix permanently allocated to the vehicle and 437 delegated to the vehicle from a home network. The former globally 438 routable IPv6 address is used as the NEMO Care-of Address (CoA) 439 and the latter as the NEMO Home Address (HoA). 441 o for V2V communication, i.e. when no infrastructure is available, 442 OBUs can use link-local addresses (default ones or with a C2C-CC 443 specific prefix TBD). As described above, a portion of the VANET 444 (geographically or topologically scoped) is presented to IPv6 as a 445 single, link-local multicast link. Therefore the link-local 446 address can be used for multi-hop communications within the VANET; 448 o RSUs can either act as IPv6 Access Routers or as bridges connected 449 to external IPv6 Access Routers. Different Access Routers are 450 responsible for announcing different network prefixes with global 451 validity. As a consequence, when roaming between different Access 452 Routers, vehicles experience layer 3 handovers. 454 When infrastructure access via RSUs is available, IPv6 support in 455 C2C-CC systems is enhanced with Mobility Support. As a vehicle 456 includes a set of attached devices (AUs), NEMO Basic Support is the 457 default protocol selected by the C2C-CC for maintaining ongoing 458 sessions during L3 handovers. 460 3.1.3. Scope of NEMO 462 The C2C-CC is defining a protocol stack for both safety and non- 463 safety applications. These two application categories put different 464 requirements on the protocol stack. Therefore the C2C-CC defined a 465 double protocol stack which is depicted in Figure 2. Applications 466 that are subject to safety requirements use the left part, whereas 467 applications that do not require these particular features use the 468 right part of the stack. The left part of the stack provides 469 functionalities like geographic packet distribution, information 470 dissemination according to relevance, information aggregation using 471 cross-layer analysis, security and plausibility checks at different 472 protocol layers. The right part of the stack is designed for non- 473 safety applications and for non-critical applications, which can 474 still support safety. 476 The deployment of NEMO in C2C-CC systems is achieved through the 477 right part of the stack depicted in Figure 2 and targets non-safety 478 applications. Nevertheless, applications using NEMO might indirectly 479 support safety applications. Example use cases are listed in 480 Section 4. 482 3.2. ISO TC204 WG 16 (CALM) 484 ISO TC 204 WG 16 (CALM) is working on "Wide Area Communications 485 Protocols and Interfaces" and was established in year 2000. The WG 486 is itself devided into a number of sub-groups. The purpose of this 487 WG is specifying a protocol architecture from the physical layer up 488 to the application layer and designed for all ITS types of 489 communications media. 491 The CALM handbook [calm-handbook] gives an overview of the system and 492 protocol architecture. In essence, this document defines a protocol 493 stack that offers specialized functionalities and interfaces to 494 safety and non-safety applications and does not rely on a specific 495 communication technology. This protocol stack allows for both IP and 496 non-IP types of communications. The IP version 6 is the version 497 considered for IP types of flows. 499 3.2.1. System and Protocol Architecture 501 Vehicles are equipped with networks logically composed of an 502 (potentially multiple) OBU(s) and potentially multiple AUs. An AU is 503 typically a dedicated device that executes a single or a set of 504 applications and utilizes the OBU communication capabilities. An AU 505 can be an integrated part of a vehicle and be permanently connected 506 to an OBU. It can also be a portable device such as laptop, PDA or 507 game pad that can dynamically attach to (and detach from) an OBU. AU 508 and OBU are usually connected with wired connection, but the 509 connection can also be wireless, such as Bluetooth. The distinction 510 between AU and OBU is logical, they can also reside in a single 511 physical unit. 513 Vehicles' OBUs and stationary units along the road, termed road-side 514 units (RSUs), form a self-organizing network. An OBU is equipped 515 with a number of short range, medium range and long range wireless 516 communication devices, typically IEEE 802.11p [IEEE.802-11p-d3-0], 517 IEEE 802.11a/b/g or 3G. OBUs can communicate with one another, either 518 directly if wireless connectivity exist among them, or via multi-hop 519 communication where data is forwarded from one OBU to another until 520 it reaches its destination, or through the roadside infrastrucure, or 521 through the Internet. 523 The primary role of an RSU is improvement of road safety and road 524 traffic. RSUs have two possible configuration modes: as isolated 525 nodes, they execute applications and/or extend the coverage of the ad 526 hoc network implementing routing functionalities. As attachment 527 point connected to an infrastructure network, RSUs distribute 528 information originated in the infrastructure and offer connectivity 529 to the vehicles. As result, for example, the latter configuration 530 allows AUs registered with an OBU to communicate with any host 531 located in the Internet, when at least one RSU connected to a network 532 infrastructure is available. 534 An OBU is equipped with alternative wireless technologies for both 535 safety and non-safety applications. For example, an OBU may also 536 communicate with Internet nodes or servers via public wireless LAN 537 hot spots (PHS) or wide coverage/cellular networks (e.g. UMTS, GPRS) 538 operated individually or by wireless Internet service providers. 539 While RSUs for Internet access are typically set up with a controlled 540 process by a CALM key stake holder, such as road administrators or 541 other public authorities, public hot spots are usually set up in a 542 less controlled environment. These two types of infrastructure 543 access, RSU and PHS, also correspond to different applications types. 544 Other communication technologies not currently available or de facto 545 considered in the CALM architecture may be added at will. 547 In Figure 3, RSU and OBU1 have direct connectivity, whereas OBU2 is 548 out of RSU radio coverage but can communicate with it through multi- 549 hop routing or through the Internet. 551 | Internet | 552 | | 553 +---+-----------------+-+ 554 | | 555 Access +--+-+ +--+-+ Access 556 Router | AR | | AR | Router 557 +--+-+ +--+-+ 558 | | 559 --+---+--- --+---+-- 560 | | 561 Road Side +--+--+ +--+--+ Public 562 Unit | RSU | | PHS | Hot Spot 563 +---+-+ +---+-+ 564 | | 565 /\ /\ 567 \_ \_ 568 \_ \_ 569 \ \ 571 Optional \/ \/ 572 IEEE 802.11a/b/g and 802.11p | | __ \/ Optional IEEE 573 Interfaces +--+---+--+ \__ \/ | 802.11a/b/g and 3G 574 | OBU1 | | | Interfaces 575 +--+---+--+ +-+-----+---+ 576 Vehicle1 | | OBU2 | On-Board 577 -+---+-+- +--+--------+ Unit 578 | | | Vehicle2 579 Application +--+-+ +-+--+ --+--+-- 580 Units | AU | | AU | | 581 +----+ +----+ +-+--+ 582 | AU | 583 +----+ 585 Figure 3: ISO's CALM scenarios 587 CALM allows all communication modes: 589 o in Vehicle-to-Vehicle (V2V) mode, data packets are exchanged 590 directly between OBUs, either via multi-hop or not, without 591 involving any RSU; 593 o in Vehicle-to-Infrastructure mode (V2I), an OBU exchanges data 594 packets through a RSU with an arbitrary node connected to the 595 infrastructure (potentially another vehicle not attached to the 596 same RSU). 598 o in Vehicle-to-Infrastructure-to-Vehicle mode (V2I2V), an OBU 599 exchanges data packets with another OBU through an arbitrary node 600 in the infrastructure or the Internet; 602 o in Vehicle-to-Internet mode (Internet), an OBU exchanges data 603 packets with an an arbitrary node in the Internet. 605 The current draft reference CALM architecture is specified in 606 [ISO-21217-CALM-Architecture] whereas the IPv6 networking specific 607 parts are specified in [ISO-21210-CALM-IPv6-Networking]. A 608 simplified description of the CALM Reference Architecture protocol 609 stack currently specified by ISO for OBUs/MRs is depicted in 610 Figure 4. 612 +---------------+--------------------+----------------------+ 613 | | | | 614 | Non-IP | IPv6 | IPv6 | 615 | CALM Aware | CALM-Aware | Legacy | 616 | Applications | Applications | Applications | 617 | | | | 618 +---------------+--------------------+----------------------+ 619 | | | 620 | | TCP/UDP/... | 621 | | | 622 + +--+----------------------------------------+ 623 | | | 624 | CALM FAST | IPv6 | 625 | | | 626 +------------------+---+------------------+-------+------+--+ 627 | ModifiedIEEE 802.11p | Standard WLAN | 2G/3G | CALM |..| 628 | M5/WAVE/DSRC | IEEE 802.11a/b/g | GSM | IR |..| 629 +----------------------+------------------+-------+------+--+ 631 Figure 4: CALM Protocol Stack for OBU/MR 633 Protocol blocks are explained in the following list: 635 o M5, WAVE and DSRC are IEEE 802.11p variants, in Europe, USA and 636 Japan, respectivelty: this block represents MAC and PHY layers of 637 a wireless technology based upon current draft standard IEEE 638 802.11p [IEEE.802-11p-d3-0] but modified for usage in Europe. In 639 Europe, allocation of dedicated frequencies around 5.9 GHz for 640 safety and non-safety applications is in progress. Expected 641 communication range in line of sight is around 500m. 643 o IEEE 802.11a/b/g: this block represents MAC and PHY layers 644 provided by one ore more IEEE 802.11a/b/g network interfaces. 646 o IPv6: this block represents the IPv6-based network layer protocol 647 currently defined by ISO. The specification of this layer is 648 currently under discussion. Several scenarios are proposed, one 649 for IP communications without mobility management, one for IP 650 communications with host-mobility management (MIPv6), and one with 651 IP communications with network mobility management (NEMO). The 652 former two are out of scope of the present document. This block 653 comprises the NME (Network Management Entity) which is able to 654 interoperate with other layers in order to negociate priority flow 655 requirements 657 o CALM FAST: this block represents a network protocol specifically 658 designed by ISO TC204 WG16 for time critical safety applications 659 and running exclusively over IEEE 802.11p. Both non-IP and IPv6 660 CALM Aware applications may use CALM FAST. Non-IP applications 661 uses it directly as the tranport. 663 o CALM Aware Applications (IPv6 and non-IP): this block represents 664 specifically designed ITS applications. CALM Aware applications 665 are ranged into IP and non IP applications. This block comprises 666 the CME (CALM Management Entity) which is able to interoperate 667 with lower layers in order to negociate priority flow 668 requirements. Non-IP applications uses CALM FAst as the tranport 670 3.2.2. IPv6 Deployment 672 The CALM architecture includes IPv6 as mandatory part of its 673 specified protocol architecture. 675 The following informational list briefly summarizes currently 676 discussed design concepts: 678 o in order to avoid address resolution procedures, vehicles use only 679 IPv6 addresses with as host part an EUI-64 identifier derived from 680 the MAC address. Privacy issues described in [RFC3041] are 681 strongly alleviated through the use of temporary, changing MAC 682 addresses, which are assigned in a set to every vehicle (as part 683 of their assigned "pseudonyms"); 685 o according to the current availability of infrastructure 686 connectivity, OBUs can use (at least) 2 types of globally routable 687 IPv6 addresses: an IPv6 address configured using standard IPv6 688 stateless address configuration from Router Advertisements sent by 689 RSUs connected to a network infrastructure and an IPv6 address 690 configured from a prefix permanently allocated to the vehicle and 691 delegated to the vehicle from a home network. The former globally 692 routable IPv6 address is used as the NEMO Care-of Address (CoA) 693 and the latter as the NEMO Home Address (HoA). In addition, a 694 self-generated IPv6 address with as prefix part a pre-defined IPv6 695 prefix (either reserved for ISO CALM communications or a general 696 purpose one) may be used for ad-hoc communications with other 697 OBUs; 699 o RSUs can either act as IPv6 Access Routers or as bridges connected 700 to external IPv6 Access Routers. Different Access Routers are 701 responsible for announcing different network prefixes with global 702 validity. As a consequence, when roaming between different Access 703 Routers, vehicles experience layer 3 handovers. 705 3.2.3. Scope of NEMO 707 In all the methods for use of IPv6 in the CALM architecture as 708 described above, the IPv6 layer is meant to be enhanced with Mobility 709 Support. As a vehicle includes a set of attached devices (AUs), NEMO 710 Basic Support is the default protocol selected by ISO for maintaining 711 ongoing sessions during L3 handovers. 713 4. NEMO Example Use Cases 715 In this section, the main use cases are listed that have been 716 identified by the C2C-CC and ISO for usage of NEMO: notification 717 services, peer-to-peer applications, upload/download services, 718 navigation services, multimedia applications. 720 4.1. Notification Services 722 A generic notification service delivers information to subscribers by 723 means of the Internet. After subscribing the service with a 724 provider, a user is notified when updates are available. Example 725 services are weather, traffic or news reports, as well as commercial 726 and technical information from the car producer or other companies. 728 In this use case, a pre-defined address belonging to the MNP is 729 registered to the service provider. The service provider sends the 730 updates to this address which does not change while the vehicle 731 changes point of attachment. 733 4.2. Peer-to-peer Applications 735 A generic peer-to-peer application exchanges data directly between 736 vehicles, without contacting any application server. Data traffic 737 goes through a network infrastructure (V2I) or directly between cars 738 when the infrastructure is not available (V2V). Example applications 739 are vehicle-to-vehicle instant messaging (chat) and off-line 740 messaging (peer-to-peer email), vehicle-to-vehicle voice over IP and 741 file exchange. 743 4.3. Upload and Download Services 745 A generic upload/download service via the Internet consists in simple 746 file exchange procedures with servers located in the Internet. The 747 service is able to resume after a loss of connectivity. 749 4.4. Vehicles Monitoring 751 Vehicles monitoring services allow car manufacturers, car garages and 752 other trusted parties to remotely monitor vehicle statistics. Data 753 is collected by an AU and sent by the OBU to the service center via 754 the Internet. 756 As an example, car manufacturers or garages offering this service 757 could deploy NEMO Home Agents to serve thousands of cars. 759 4.5. Infotainment Applications 761 TBD by ISO CALM 763 4.6. Navigation Services 765 TBD by ISO CALM 767 5. NEMO Route Optimization Scenarios 769 In this section, operational characteristics of automotive 770 deployments of NEMO are described that are relevant for the design of 771 Route Optimization techniques. In particular a restriction of the 772 general solution space for RO and motivations for RO requirements 773 described in Section 6 are provided. 775 With respect to the classification of NEMO Route Optimization 776 scenarios described in [RFC4889], the non-nested NEMO RO case 777 (Section 3.1) is considered as the most important for the automotive 778 deployment. However, MIPv6-enabled AUs (i.e. VMNs) and nested NEMOs 779 are allowed in ISO CALM but not specifically addressed in the 780 specifications. 782 The requirements defined in this document refer to RO between MR and 783 CE (Correspondent Entity). According to the automotive use cases, 784 the CE can be: 786 1. Another vehicle, i.e. another automotive MR. 788 2. A dedicated node (host or router) installed on the roadside (2a) 789 or in the Internet (2b) for automotive applications. 791 3. An arbitrary node in the Internet. 793 In cases 1 and 2, the CE is a newly deployed entity. Whereas the 794 communicating peers in case 1 are obvious, case 2 includes for 795 example information points installed along the road, control centers, 796 notification points and infotainment service providers located in the 797 infrastructure. 799 The suboptimal routing due to the lack of RO has the most negative 800 impact when the topological distance between MR and CE is 801 considerably smaller than between MR and HA. This is highly likely 802 to occour in case 1 (e.g. two neighboring vehicles communicating with 803 each others) and case 2a (e.g. vehicles receiving updates from 804 information points installed on the roadside). For these two cases, 805 the suboptimal routing might represent a limiting factor for the 806 system performance and, in turn, a limiting factor for the deployment 807 of NEMO. 809 In cases 2b and 3, the impact of suboptimal routing depends on the 810 arbitrary CE topological position. At this point of time no 811 particular assumption can be made on the topological position of CE 812 in case 2b and, obviously, in case 3. Consequently, the case 1 and 813 2a deserve a higher priority with respect to the definition of a NEMO 814 RO solution for automotive applications. 816 Any available information about the geographical or topological 817 position of the CE is relevant for the MR in order to apply RO. In 818 this respect, external information might be used to define policy 819 rules specifying whether or not RO should be enabled with a 820 particular pre-defined CE, which is known in advanced to the MR. 822 6. NEMO Route Optimization Requirements 824 Figure 5 summarizes which requirement applies to both C2C-CC and ISO, 825 or only one of these. 827 6.1. Req 1 - Separability 829 An RO technique, including its establishment procedure, MUST have the 830 ability to be enabled on a per-flow basis according to pre-defined 831 policies. Policies criteria for the switching to RO MUST at least 832 include the end points' addresses and the MNP for which RO is to be 833 established. Policies MAY change dynamically. 835 In some scenarios it might not be beneficial to activate RO due to 836 the intermittent connectivity. Based on external information, a 837 management instance of the MR can dynamically specify policies for RO 838 establishment of a particular IPv6 flow. Furthermore, policies can 839 prevent unnecessary or unwanted RO sessions to take place (e.g. DNS 840 queries, location privacy protection, etc.). In case of MRs serving 841 multiple MNPs (e.g. served by different HAs or MNPs that vary only in 842 the length), the policies allow for specifying for which MNP RO 843 should be established (i.e. prefix including length). 845 6.2. Req 2 - RO Security 847 This requirements consists of the following sub-requirements: 849 o The RO scheme MUST permit the receiver of a BU to validate an MR's 850 ownership of the CoAs claimed by an MR. 852 o The RO scheme MUST ensure that only explicitly authorized MRs are 853 able to perform a binding update for a specific MNP. 855 o If the RO scheme makes use of cryptographic material, this SHOULD 856 be the same material already installed on vehicles as defined by 857 automotive consortia. 859 6.3. Req 3 - Binding Privacy Protection 861 An RO technique MUST protect the MR's binding privacy against on-path 862 nodes' attacks. 864 In other words, the RO technique must not expose the content of the 865 binding (CoA, MNP/HoA) to nodes other than the intended CEs. The 866 rationale behind this requirement is the fact that mechanisms that 867 are being designed by the automotive industry for privacy protection 868 might be made ineffective if the content of the binding is revealed. 869 In fact, a common approach in automotive applications consists of 870 equipping a vehicle with a set of CoAs to be used for limited time 871 intervals. Consecutive binding updates, where the MNP/HoA is 872 constant and transmitted as clear text, could be used to unveal the 873 user's identity by linking together the different addresses. 875 6.4. Req 4 - Multihoming 877 An RO technique MUST allow an MR to be simultaneously connected to 878 multiple access networks, having multiple prefixes and Care-Of 879 Addresses in a MONAMI6 context, and be served by multiple HAs. 881 Adopting the classification of [RFC4980], the automotive NEMO 882 deployment includes at least the cases (1,n,n), (n,1,1) and (n,n,n). 884 Case (1,n,n) takes place when a single MR is installed in the 885 vehicle's OBU but different MNPs/HAs are used for different purposes 886 (e.g. vehicle monitoring, traffic information, infotainment) or to 887 achieve better fault tolerance. Cases (n,1,1) and (n,n,n) take place 888 when the vehicle's connectivity is enhanced by installing additional 889 NEMO MRs in a separated unit in a later stage. An RO technique must 890 not prevent any of these three configurations from working properly. 892 6.5. Req 5 - Minimum Signaling 894 An RO technique MUST be capable of minimum signaling. The number of 895 per-flow signaling messages for the establishment of RO SHOULD be 896 smaller than TBD and the number of per-flow signaling messages upon a 897 layer 3 handover should be smaller than TBD. 899 6.6. Req 6 - Switching HA 901 An RO technique MUST allow a MR to switch from one HA to another one 902 topologically distant from the first one. 904 A vehicle is typically served by various network access operators, 905 simultaneously, and over a period of time depending on its 906 geographical location. Since Internet services providers providing 907 the HA servive and the MNP may be topologically distant from the OBU, 908 multiple HAs belonging to the same Internet service operator might be 909 deployed in order to decrease transmission delays. In such a case 910 the RO solution shall allow the OBU to select the best HA according 911 to its location and to switch from one HA to another HA. 913 +====================================================+ 914 | | C2C-CC | ISO CALM | 915 +====================================================+ 916 | #1: Separability | x | x | 917 +--------------------------------+--------+----------+ 918 | #2: RO Security | x | x | 919 +--------------------------------+--------+----------+ 920 | #3: Privacy Protection | x | x | 921 +--------------------------------+--------+----------+ 922 | #4: Multihoming | x | x | 923 +--------------------------------+--------+----------+ 924 | #5: Efficient Signaling | x | x | 925 +--------------------------------+--------+----------+ 926 | #6: Switching HAs | | x | 927 +====================================================+ 929 Figure 5: C2C-CC and ISO CALM requirements 931 7. IANA Considerations 933 This document does not require any IANA action. 935 8. Security Considerations 937 This document does not specify any protocol therefore does not create 938 any security threat. However, it specifies requirements for a 939 protocol that include security and privacy issues. 941 9. Acknowledgments 943 The authors would like to thank the members of TC204 WG16 and the 944 work groups PHY/MAC/NET and APP of the C2C-C Consortium. The authors 945 particularly appreciated the helpful support of Carlos Bernardos 946 Cano, Tim Leinmueller, Bernd Bochow, Andras Kovacs and Matthias 947 Roeckl. 949 10. References 951 10.1. Normative References 953 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 954 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 955 RFC 3963, January 2005. 957 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 958 in IPv6", RFC 3775, June 2004. 960 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 961 Stateless Address Autoconfiguration in IPv6", RFC 3041, 962 January 2001. 964 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 965 Networks", RFC 2464, December 1998. 967 10.2. Informative References 969 [RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network 970 Mobility Route Optimization Problem Statement", July 2007. 972 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 973 Mobility Route Optimization Solution Space Analysis", 974 July 2007. 976 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 977 Terminology", RFC 4885, July 2007. 979 [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 980 Multihoming in Network Mobility Support", RFC 4980, 981 October 2007. 983 [I-D.ietf-mext-aero-reqs] 984 Eddy, W., Ivancic, W., and T. Davis, "NEMO Route 985 Optimization Requirements for Operational Use in 986 Aeronautics and Space Exploration Mobile Networks", 987 draft-ietf-mext-aero-reqs-02 (work in progress), May 2008. 989 [c2ccc-web] 990 "Car2Car Communication Consortium Official Website", 991 http://www.car-2-car.org/ . 993 [c2ccc-manifesto] 994 "Car2Car Communication Consortium Manifesto", 995 http://www.car-2-car.org/index.php?id=570 , May 2007. 997 [calm-handbook] 998 "The CALM Handbook", http://www.calm.hu , May 2005. 1000 [ISO-21210-CALM-IPv6-Networking] 1001 "Intelligent Transport Systems - Continuous air interface, 1002 long and medium range (CALM) - Networking Protocols", ISO 1003 Draft DIS 21210, February 2008. 1005 [ISO-21217-CALM-Architecture] 1006 "Intelligent Transport Systems - Communications access for 1007 land mobiles (CALM) - Architecture", ISO Draft DIS 21217, 1008 June 2008. 1010 [IEEE.802-11p-d3-0] 1011 "Draft Amendment to Standard for Information Technology . 1012 Telecommunications and information exchange between 1013 systems . Local and Metropolitan networks . Specific 1014 requirements - Part 11: Wireless LAN Medium Access Control 1015 (MAC) and Physical Layer (PHY) specifications: Amendment 1016 3: Wireless Access in Vehicular Environments (WAVE)", 1017 IEEE P802.11p/D1.0, February 2006. 1019 Authors' Addresses 1021 Roberto Baldessari 1022 NEC Europe Network Laboratories 1023 Kurfuersten-anlage 36 1024 Heidelberg 69115 1025 Germany 1027 Phone: +49 6221 4342167 1028 Email: roberto.baldessari@nw.neclab.eu 1030 Thierry Ernst 1031 INRIA 1032 INRIA Rocquencourt 1033 Domaine de Voluceau B.P. 105 1034 Le Chesnay, 78153 1035 France 1037 Phone: +33-1-39-63-59-30 1038 Fax: +33-1-39-63-54-91 1039 Email: thierry.ernst@inria.fr 1040 URI: http://www.nautilus6.org/~thierry 1042 Andreas Festag 1043 NEC Deutschland GmbH 1044 Kurfuersten-anlage 36 1045 Heidelberg 69115 1046 Germany 1048 Phone: +49 6221 4342147 1049 Email: andreas.festag@nw.neclab.eu 1051 Massimiliano Lenardi 1052 Hitachi Europe SAS Sophia Antipolis Laboratory 1053 Immeuble Le Theleme 1054 1503 Route des Dolines 1055 Valbonne F-06560 1056 France 1058 Phone: +33 489 874168 1059 Email: massimiliano.lenardi@hitachi-eu.com 1061 Full Copyright Statement 1063 Copyright (C) The IETF Trust (2008). 1065 This document is subject to the rights, licenses and restrictions 1066 contained in BCP 78, and except as set forth therein, the authors 1067 retain all their rights. 1069 This document and the information contained herein are provided on an 1070 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1071 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1072 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1073 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1074 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1075 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1077 Intellectual Property 1079 The IETF takes no position regarding the validity or scope of any 1080 Intellectual Property Rights or other rights that might be claimed to 1081 pertain to the implementation or use of the technology described in 1082 this document or the extent to which any license under such rights 1083 might or might not be available; nor does it represent that it has 1084 made any independent effort to identify any such rights. Information 1085 on the procedures with respect to rights in RFC documents can be 1086 found in BCP 78 and BCP 79. 1088 Copies of IPR disclosures made to the IETF Secretariat and any 1089 assurances of licenses to be made available, or the result of an 1090 attempt made to obtain a general license or permission for the use of 1091 such proprietary rights by implementers or users of this 1092 specification can be obtained from the IETF on-line IPR repository at 1093 http://www.ietf.org/ipr. 1095 The IETF invites any interested party to bring to its attention any 1096 copyrights, patents or patent applications, or other proprietary 1097 rights that may cover technology that may be required to implement 1098 this standard. Please address the information to the IETF at 1099 ietf-ipr@ietf.org.