idnits 2.17.1 draft-ietf-ipoib-link-multicast-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: It is up to the network administrator to select a link MTU to use when configuring an IPoIB link. The link MTU SHALL not be greater than the MTU of any IB device on the IPoIB link minus the size of the "Type" field encapsulated in the payload [IPoIB_ENCAP]. Here the IB devices include IB switches, CAs, or routers. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In case an IPoIB link spans more than one IB subnet, the IPoIB link MTU MUST not exceed the path MTU of any path connecting two nodes in the same IB partition. It is up to the network administrator to determine the appropriate path MTU value that will work for any node in the same IPoIB link. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2461 (ref. 'DISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'IBTA' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H.K. Jerry Chu 3 Sun Microsystems 4 Vivek Kashyap 5 IBM 6 Expires: December, 2002 June, 2002 8 IP link and multicast over InfiniBand networks 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society (date). All Rights Reserved. 32 Abstract 34 This document specifies a method for setting up IP subnets and 35 multicast services over InfiniBand(TM) networks. Discussions in this 36 document are applicable to both IPv4 and IPv6, unless explicitly 37 specified. A separate document will cover unicast and encapsulation 38 of IP datagrams over InfiniBand networks. 40 Table of Contents 41 1.0 Introduction 42 2.0 Terminology 43 3.0 Basic IPoIB Transport - Unreliable Datagram 44 4.0 IB Multicast Architecture 45 5.0 IB Links vs IPoIB Links 46 6.0 Setting up an IPoIB Link 47 6.1 Maximum Transmission Unit 48 6.2 IPoIB Link Q_Key 49 6.3 Other Link Attributes 50 7.0 The IPoIB Broadcast Group 51 8.0 Mapping for other Multicast Groups 52 9.0 Sending and Receiving IP Multicast Packets 53 10.0 Security Considerations 54 11.0 Acknowledgments 55 12.0 References 56 13.0 Author's Address 57 14.0 Full Copyright Statement 59 1.0 Introduction 61 InfiniBand Architecture (IBA) defines four layers of network services 62 corresponding to layer one through layer four of the OSI reference 63 model. For the purpose of running IP over an InfiniBand (IB) 64 network, the IB link, network, and transport layers collectively 65 constitute the data link layer to the IP stack. One can find a 66 general overview of IB architecture related to IP networks in 67 [IPoIB_ARCH]. 69 This document will focus on the necessary steps in order to lay out 70 an IP network on top of an IB network. It will describe all the 71 elements of an IP over InfiniBand (IPoIB) link, how to configure its 72 associated attributes, and how to set up basic broadcast and 73 multicast services for it. IPoIB link is the building block upon 74 which an IP network consisting of many IP subnets connected by 75 routers can be built. Subnetting allows the containment of broadcast 76 traffic within a single link. It also provides certain degree of 77 isolation for administration purpose between nodes on different 78 subnets. 80 2.0 Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3.0 Basic IPoIB Transport - Unreliable Datagram 88 InfiniBand defines four types of transport services [IBTA]. They are 89 reliable connection, unreliable connection, reliable datagram, 90 unreliable datagram. IBA also defines a special raw datagram service 91 for encapsulation purpose. Both unreliable datagram and raw datagram 92 define support for multicast. They provide the basic transport 93 mechanism that best matches the IP datagram paradigm. 95 IB unreliable datagram provides many additional features such as the 96 partition key (P_Key) protection, multiple queue pairs (QPs), and 97 Q_Key protection. Moreover, it requires a 32-bit invariant CRC 98 checksum, which provides a much stronger protection against data 99 corruption, compared with the 16-bit CRC that a raw datagram carries. 101 For these reasons, IB unreliable datagram is considered to be a much 102 better choice as the basic IPoIB transport than the raw datagram, and 103 is chosen as the default IPoIB transport mechanism ([IPoIB_ARCH], 104 [IPoIB_ENCAP]). 106 4.0 IB Multicast Architecture 108 The following discussion gives a short overview of the multicast 109 architecture in InfiniBand. For a more complete description, the 110 reader is referred to [IBTA] and [IPoIB_ARCH]. 112 IBA defines two layers of multicast services. Its link layer uses 113 multicast LIDs (MLIDs), which are allocated by the Subnet Manager 114 (SM) and fall in the range between 0xC0000 to 0xFFFE (approximately 115 16k). MLIDs are used by IB switches to program their multicast 116 forwarding tables. An IB switch implementation may support much fewer 117 MLIDs in its forwarding table though. 119 IB network layer uses multicast GIDs (MGIDs), which closely resemble 120 IPv6 multicast addresses [AARCH] shown below. 122 | 8 | 4 | 4 | 112 bits | 123 +------ -+----+----+---------------------------------------------+ 124 |11111111|flgs|scop| group ID | 125 +--------+----+----+---------------------------------------------+ 127 Figure 1 129 [IPoIB_ARCH] describes each field in more details. 131 Since every IB multicast packet is required to carry both LRH and 132 GRH, a valid MGID and a valid MLID are both needed before a valid IB 133 multicast packet can be constructed. 135 An IB multicast group is uniquely identified by a valid MGID. Before 136 a MGID can be used within an IB subnet, either as a destination 137 address of a multicast packet, or representing a multicast group that 138 an IB node can join, an IB multicast group corresponding to the MGID 139 must be created through the Subnet Administrator (SA). Besides the 140 MGID, the creator must supply values of the path MTU, Q_Key, TClass, 141 FlowLabel, HopLimit that are appropriate for all the potential 142 clients of the multicast group to use. In return, SA will allocate a 143 MLID to be used by switches in the local IB subnet. 145 Unreliable multicast is defined by IBA as an optional functionality 146 for channel adaptors (CAs) and switches. In today's IP technology, 147 link multicast has become an indispensable function for better 148 supporting a modern IP network. For this reason, it is required that 149 an IPoIB fabric supports multicast. This includes all the CAs and 150 switches that are part of an IP network. 152 5.0 IB Links vs IPoIB Links 154 A link segment on top of which an IP subnet can be configured is 155 defined in [IPV6] as a communication facility or medium over which 156 nodes can communicate at the "link" layer. For most types of 157 communication media, the boundary between different data link 158 segments follows the physical topology of the network. E.g. an 159 Ethernet network connected by switches, hubs, or bridges usually 160 forms a single link segment and broadcast/multicast domain. Different 161 Ethernet segments can be connected together by IP routers at the 162 network layer. 164 InfiniBand defines its own link-layer and subnets consisting of nodes 165 connected by IB switches. However, the IPoIB link boundary need not 166 follow the IB link boundary. Nodes residing on different IB subnets 167 can still communicate directly with one another through IB routers at 168 the InfiniBand network layer. This communication at the network layer 169 applies to unicast as well as multicast. 171 The ultimate requirement for two nodes in the same IB fabric to 172 communicate at the IB level, besides physical connectivity, is a 173 common P_Key. 175 Partitioning in IB provides an isolation mechanism among nodes in an 176 IB fabric, much like VLANs in the Ethernet network. Each HCA (Host 177 Channel Adaptor) port of an endnode contains a P_Key table holding 178 all the valid P_Keys the port is allowed to use. The P_Key table is 179 set up by the SM of the local IB subnet. Each QP is programmed with a 180 P_Key from the local P_Key table. This P_Key is carried in all the 181 outgoing packets from the QP, and is used to compare against the 182 P_Key of incoming packets to the QP. Any packet with an invalid P_Key 183 will be discarded by the QP and trigger a P_Key violation trap. IB 184 switches may optionally enforce partition checking too. 186 Following the above, IB partitions are the natural choice for 187 defining IPoIB link boundary. It also provides much needed 188 flexibility for a network administrator to group nodes logically into 189 different subnets in a large network. 191 6.0 Setting up an IPoIB Link 193 A network administrator defines an IPoIB link by setting up an IB 194 partition and assigning it a unique P_Key. An IB partition may or may 195 not span multiple IB subnets; and whether it does or not is mostly 196 transparent to IPoIB. 198 Each node attached to the IB partition MUST have one of its HCAs 199 assigned the P_Key to use. Note that the P_key table of an HCA port 200 may contain many P_Keys. It is up to the implementation to define the 201 method by which the P_Key relevant to a particular IPoIB subnet is 202 determined and conveyed to the IPoIB stack. E.g. implementations can 203 resort to a manual configuration to choose the P_key or a set of 204 P_Keys for IPoIB use, and rely on DHCP [DHCP] to assign an IP subnet 205 number to each IPoIB link. 207 Once an IB partition is established for IPoIB use, the link MTU and 208 Q_Key are two other attributes that must be chosen before the IPoIB 209 link can be configured. 211 6.1 Maximum Transmission Unit 213 IB defines five permissible maximum payload sizes (MTUs). They are 214 256, 512, 1024, 2048 and 4096 bytes. [IPV6] requires a link MTU of 215 1280 bytes or greater. To be better compatible with Ethernet, the 216 dominant network media in both the LAN and WAN environment, the IPoIB 217 link MTU SHALL be 1500 bytes or greater. This leaves only 2048 and 218 4096 bytes as the two acceptable MTUs for IPoIB. Channel adaptors 219 supporting a MTU less than the minimal requirement can still expose 220 an acceptable MTU to IP through an adaptation layer that fragments 221 larger messages into smaller IB packets, and reassembles them on the 222 receiving end. But this must be done in a way that is transparent to 223 the IP stack. 225 It is up to the network administrator to select a link MTU to use 226 when configuring an IPoIB link. The link MTU SHALL not be greater 227 than the MTU of any IB device on the IPoIB link minus the size of the 228 "Type" field encapsulated in the payload [IPoIB_ENCAP]. Here the IB 229 devices include IB switches, CAs, or routers. 231 In general, a maximal link MTU should be employed whenever possible 232 to attain better throughput performance. One caveat is that once a 233 link MTU is chosen for a given IPoIB link, nodes connected by CAs of 234 a smaller MTU won't be able to join the link unless the whole link 235 and all the devices attached to it are reconfigured to use a smaller 236 MTU. 238 The flexibility of configuring a smaller than the full link MTU size 239 does make it easier for one to bridge an IPoIB link with an Ethernet 240 link, by setting the IPoIB link MTU to 1500 bytes. For IPv4, this may 241 require a manual configuration of a different link MTU than the 242 maximum that all the nodes support. (See 7.0 below.) For IPv6, one 243 can use the MTU option of the router advertisement [DISC] to announce 244 a smaller MTU to all the nodes. 246 In case an IPoIB link spans more than one IB subnet, the IPoIB link 247 MTU MUST not exceed the path MTU of any path connecting two nodes in 248 the same IB partition. It is up to the network administrator to 249 determine the appropriate path MTU value that will work for any node 250 in the same IPoIB link. 252 6.2 IPoIB Link Q_Key 254 A Q_Key is programmed by the source QP in every IB datagram, and is 255 compared against the Q_Key of the destination QP. A Q_Key violation 256 will cause the offending datagram to be dropped, and a Q_Key 257 violation trap to be raised. 259 A Q_Key must be selected to be used by all the QPs attached to an 260 IPoIB link. It is recommended that a controlled Q_Key be used with 261 the high order bit set. This is to prevent non-privileged software 262 from fabricating and sending out bogus IP datagrams. All QPs 263 configured to be used on a given IPoIB link SHALL be assigned the 264 same per-link Q_Key. 266 6.3 Other Link Attributes 268 TClass, FlowLabel, and HopLimit are three other attributes that are 269 required if an IPoIB link covers more than a single IB subnet. The 270 selection of these values are implementation dependent. But it must 271 take into account the topology of IB subnets comprising the IPoIB 272 link in order to allow successful communication between any two nodes 273 in the same IPoIB link. 275 7.0 The IPoIB Broadcast Group 277 Once an IB partition is created with link attributes identified for 278 an IPoIB link, the network administrator must create a special IB 279 all-node multicast group (henceforth referred to as the broadcast 280 group) with these link attributes that every node on the IPoIB link 281 can join. 283 The MGID of the broadcast group will embed in it the P_Key of the IB 284 partition that defines the IPoIB link. A special signature is also 285 embedded to identify the MGID for IPoIB use only. For IPv4 over IB, 286 the signature will be "0x401B". For IPv6 over IB, the signature will 287 be "0x601B". 289 For an IPv4 subnet, the MGID for this special IB multicast group 290 SHALL have the following format: 292 | 8 | 4 | 4 | 16 bits | 16 bits | 48 bits | 32 bits | 293 +--------+----+----+----------------+---------+----------+---------+ 294 |11111111|0001|scop|0100000000011011|< P_Key >|00.......0|| 295 +--------+----+----+----------------+---------+----------+---------+ 297 Figure 2 299 For an IPv6 subnet, the format of the MGID SHALL look like this: 301 | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | 302 +--------+----+----+----------------+---------+--------------------+ 303 |11111111|0001|scop|0110000000011011|< P_Key >|000.............0001| 304 +--------+----+----+----------------+---------+--------------------+ 306 Figure 3 308 As for the scop bits, if the IPoIB link is fully contained within a 309 single IB subnet, the scop bits SHALL be set to 2 (link-local). 310 Otherwise the scope will be set higher. 312 The broadcast group for IPv4 will serve to provide a broadcast 313 service for protocol like ARP to use. 315 When a node is brought up on an IPoIB link identified by a P_Key, it 316 must look for the right broadcast group to join. This is done by 317 constructing the MGID with the link P_Key and the IPoIB signature. 318 The node SHOULD always look for a MGID of a link-local scope first 319 before attempting one with a greater scope. 321 Once the right MGID and broadcast group are identified, the local 322 node SHOULD use the MTU associated with the broadcast group. In case 323 the MTU of the broadcast group is greater than what the local HCA can 324 support, the node can not join the IPoIB link and operate as an IP 325 node. Otherwise the local node must join the broadcast group and use 326 the rest of link attributes associated with the group for all future 327 communication to the link. 329 In addition to the special all-node multicast group for broadcast 330 purpose, an all-router multicast group SHOULD be created at link 331 configuration time if an IP router will be attached to the link. This 332 is to facilitate IP multicast operations described later. An IB 333 multicast group for the all-router MGID must cover every IB subnet 334 that the IPoIB link encompasses. The format of the all-router MGID 335 will be covered in next section. 337 8.0 Mapping for other Multicast Groups 339 The support of general IP multicast [IPMULT] over IB is similar to 340 the case of the special broadcast group discussed above. An 341 algorithmic mapping is used so that given an IP multicast address, 342 individual host can compute the corresponding IB multicast address 343 (MGID) all by itself without having to consult an external entity. 344 This also removes the need for an externally maintained IP to IB 345 multicast mapping table. 347 The IPoIB multicast mapping is depicted in Figure 4. The same mapping 348 function is used for both IPv4 and IPv6 except the IPoIB signature 349 field. 351 | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | 352 +------ -+----+----+-----------------+---------+--------------------+ 353 |11111111|0001|scop||< P_Key >| group ID | 354 +--------+----+----+-----------------+---------+--------------------+ 356 Figure 4 358 Since a MGID allocated for transporting IP multicast datagrams is 359 considered only a transient link-layer multicast address, all IB 360 MGIDs allocated for IPoIB purpose SHOULD have T = 1. The scope bits 361 SHALL be the same as that of the all-node MGID for the same IPoIB 362 link. 364 The IP multicast address is used together with a given IPoIB link 365 P_Key to form the MGID of the IB multicast group. For IPv6 the lower 366 80-bit of the group ID is used directly in the lower 80-bit of the 367 MGID. For IPv4, the group ID is only 28-bit long and the rest of the 368 80 bits are filled with 0. 370 The rest of the bits are the same as those of the broadcast MGID. 371 E.g. on an IPoIB link that is fully contained within a single IB 372 subnet with a P_Key of 8, the MGIDs for the all-router multicast 373 group with group ID 2 [AARCH, IGMP2] are: 375 FF12:401B:8:0:0:0:0:2 377 or 379 FF12:401B:8::2 380 for IPv4 in a compressed format, and 382 FF12:601B:8:0:0:0:0:2 384 or 386 FF12:601B:8::2 388 for IPv6 in a compressed format. 390 A special case exists for the IPv4 limited broadcast address 391 "255.255.255.255" [HOSTS]. The address SHALL be mapped to the 392 broadcast MGID for IPv4 networks as described in section 7 above. 393 Also the IPv6 all-node multicast address "FF0X::1" [AARCH] maps 394 naturally to the the special broadcast MGID for IPv6 networks. 396 9.0 Sending and Receiving IP Multicast Packets 398 For any MGID the equivalent IB multicast group must be created first 399 before use. The implication for a sender is that to send a packet 400 destined for an IP multicast address, it must first check for the 401 existence of the IB multicast group corresponding to the MGID on the 402 outbound link. If one already exists, the MLID associated with the 403 multicast group is used as the DLID for the packet. Otherwise, it 404 implies no member exists on the local link. The packet should be 405 forwarded to locally connected routers. This is to allow local 406 routers to forward the packet to multicast listeners on remote 407 networks. The specific mechanism for a sender to forward packets to 408 routers are left to implementations. One can use, for example, the 409 broadcast group, or the all-router multicast group for this purpose. 411 A sender of multicast packets should cache information regarding the 412 the MLID and other attributes of the target IB multicast group in 413 order to avoid expensive SA calls on every outgoing multicast packet. 414 The cache may need to be validated periodically. E.g., if SA supports 415 multicast group create/delete traps, the sender should register to 416 monitor the status of the target IB multicast group through event 417 notification. If multicast packets were sent to the all-router 418 multicast group because no local listener existed, the sender must be 419 notified by SA when listeners show up later on the local link. This 420 allows the sender to change the forwarding to the right multicast 421 group. 423 For a node to join an IP multicast group, it must first construct a 424 MGID for it, using the rule described above. Note that it must 425 remember the scope bits from the all-node MGID, and use the same 426 scope in all the MGIDs it constructs. 428 The local node then calls SA to join the IB multicast group 429 corresponding to the MGID. If the group doesn't already exist, one 430 must be created first with the IPoIB link MTU. For the rest of 431 attributes, it is recommended the same values from the all-node 432 multicast/broadcast group be used. 434 The join call enables SM to program local IB switches and routers 435 with the new multicast information. Specifically it causes an IB 436 switch to add the LID of the caller to its forwarding table entry 437 corresponding to the MLID allocated for the group. It also causes an 438 IB router to attach itself to the IB multicast tree corresponding to 439 the MGID. 441 When a node leaves an IP multicast group, it SHOULD notify the SA in 442 order for all the related resources to be freed up. This gives SM an 443 opportunity to delete an IB multicast group that is no longer in use, 444 and free up the MLID allocated for it. The specific algorithm is 445 implementation-dependent, and is out of the scope of this document. 447 Note that for an IPoIB link that spans more than one IB subnet 448 connected by IB routers, an adequate multicast forwarding support at 449 the IB level is required for multicast packets to reach listeners on 450 remote IB subnets. The specific mechanism for this will be covered in 451 [IBTA], and is beyond the scope of IPoIB. 453 10.0 Security Considerations 455 All the operations for creating and configuring an IPoIB link 456 described in this document, including assigning P_Keys to CAs, 457 creating IB multicast groups in SA, creating and attaching QPs to IB 458 multicast groups,... etc are privileged operations, and MUST be 459 protected by the underlying operating system. This is to prevent 460 malicious, non- privileged software from hijacking important 461 resources and configurations. E.g. A bogus IPoIB broadcast group may 462 prevent a proper one from being created when the network 463 administrator tries to set up a link. 465 Controlled Q_Keys SHOULD be used in IPoIB links. This is to prevent 466 non-privileged software from fabricating IP datagrams to send, as 467 mentioned in section 6.2. 469 11.0 Acknowledgments 471 The authors would like to thank Bruce Beukema, David Brean, Dan 472 Cassiday, Aditya Dube, Yaron Haviv, Michael Krause, Thomas Narten, 473 Erik Nordmark, Greg Pfister, Renato Recio, Satya Sharma, and David L. 474 Stevens for their suggestions and many clarifications on the IBA 475 specification. 477 12.0 References 479 [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing 480 Architecture", RFC 2373, July 1998. 482 [DHCP] R. Droms "Dynamic Host Configuration Protocol", RFC 2131, 483 March 1997. 485 [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 486 Discovery for IP Version 6 (IPv6)", RFC 2461, December 487 1998. 489 [HOSTS] Braden R., "Requirements for Internet Hosts -- 490 Communication Layers", RFC 1122, October 1989 492 [IBTA] InfiniBand Architecture Specification, Release 1.0.a by 493 InfiniBand Trade Association at www.infinibandta.org 495 [IGMP2] Fenner W., "Internet Group Management Protocol, Version 2", 496 RFC 2236, November 1997. 498 [IPMULT] Deering S., "Host Extensions for IP Multicasting", RFC 499 1112, August 1989. 501 [IPoIB_ARCH] draft-ietf-ipoib-architecture-01.txt 503 [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-01.txt 505 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 506 (IPv6) Specification", RFC 2460, December 1998. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 13.0 Author's Address 513 H.K. Jerry Chu 514 17 Network Circle, UMPK17-201 515 Menlo Park, CA 94025 516 USA 518 Phone: +1 650 786-5146 519 EMail: jerry.chu@sun.com 521 Vivek Kashyap 522 IBM 523 15450, SW Koll Parkway 524 Beaverton, OR 97006 526 Phone: 503 578 3422 527 EMail: vivk@us.ibm.com 529 14.0 Full Copyright Statement 531 Copyright (C) The Internet Society (2002>. All Rights Reserved. 533 This document and translations of it may be copied and furnished to 534 others, and derivative works that comment on or otherwise explain it 535 or assist in its implementation may be prepared, copied, published 536 and distributed, in whole or in part, without restriction of any 537 kind, provided that the above copyright notice and this paragraph are 538 included on all such copies and derivative works. However, this 539 document itself may not be modified in any way, such as by removing 540 the copyright notice or references to the Internet Society or other 541 Internet organizations, except as needed for the purpose of 542 developing Internet standards in which case the procedures for 543 copyrights defined in the Internet Standards process must be 544 followed, or as required to translate it into languages other than 545 English. 547 The limited permissions granted above are perpetual and will not be 548 revoked by the Internet Society or its successors or assigns. 550 This document and the information contained herein is provided on an 551 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 552 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 553 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 554 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 555 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.