idnits 2.17.1 draft-ietf-mpls-tc-mib-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == Mismatching filename: the document gives the document name as 'draft-nadeau-mpls-tc-mib-00', but the file name used is 'draft-ietf-mpls-tc-mib-00' == 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 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 581 has weird spacing: '...for the purpo...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 2001) is 8410 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'LblStk' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'LWFRN' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'MLDPATM' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'Assigned' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'IPSEC' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'IFMIB' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'ATOMMIBTC' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'RSVPTE' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'CRLDP' is defined on line 525, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 1700 (ref. 'Assigned') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 Summary: 20 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Thomas D. Nadeau 2 Cisco Systems, Inc. 3 Expires: October 2001 4 Joan Cucchiara 6 Cheenu Srinivasan 7 Tachion Networks, Inc. 9 Arun Viswanathan 10 Force10 Networks, Inc. 12 Hans Sjostrand 13 ipUnplugged 15 April 2001 17 Definitions of Textual Conventions and OBJECT-IDENTITIES 18 for Multi-Protocol Label Switching Management 20 draft-nadeau-mpls-tc-mib-00.txt 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC 2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Abstract............................................2 47 2. Introduction........................................2 48 3. Terminology.........................................2 49 4. The SNMP Management Framework.......................3 50 5. Definitions.........................................3 51 6. Security Considerations.............................9 52 7. References..........................................9 53 8. Authors' Addresses.................................12 54 9. Full Copyright Statement...........................12 56 1. Abstract 57 This memo describes Textual Conventions and OBJECT-IDENTITIES used 58 for managing MPLS networks. 60 2. Introduction 62 This memo defines a portion of the Management Information Base (MIB) 63 for use with network management protocols in the Internet community. 64 In particular, it defines Textual Conventions used in IETF MPLS and 65 MPLS-related MIBs. 67 Comments should be made directly to the MPLS mailing list at 68 mpls@uu.net. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 71 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 72 "OPTIONAL" in this document are to be interpreted as described in 73 RFC 2119, reference [BCP14]. 75 For an introduction to the concepts of MPLS, see [MPLSArch]. 77 3. Terminology 79 This document uses terminology from the document describing the 80 MPLS architecture [MPLSArch]. 82 4. The SNMP Management Framework 84 The SNMP Management Framework presently consists of five major 85 components: 87 o An overall architecture, described in RFC 2571 [RFC2571]. 89 o Mechanisms for describing and naming objects and events for the 90 purpose of management. The first version of this Structure of 91 Management Information (SMI) is called SMIv1 and described in 92 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 93 1215 [RFC1215]. The second version, called SMIv2, is described 94 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 95 STD 58, RFC 2580 [RFC2580]. 97 o Message protocols for transferring management information. The 98 first version of the SNMP message protocol is called SNMPv1 and 99 described in STD 15, RFC 1157 [RFC1157]. A second version of 100 the SNMP message protocol, which is not an Internet standards 101 track protocol, is called SNMPv2c and described in RFC 1901 103 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 104 message protocol is called SNMPv3 and described in RFC 1906 105 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 107 o Protocol operations for accessing management information. The 108 first set of protocol operations and associated PDU formats is 109 described in STD 15, RFC 1157 [RFC1157]. A second set of 110 protocol operations and associated PDU formats is described in 111 RFC 1905 [RFC1905]. 113 o A set of fundamental applications described in RFC 2573 114 [RFC2573] and the view-based access control mechanism described 115 in RFC 2575 [RFC2575]. 117 A more detailed introduction to the current SNMP Management Framework 118 can be found in RFC 2570 [RFC2570]. 120 Managed objects are accessed via a virtual information store, termed 121 the Management Information Base or MIB. Objects in the MIB are 122 defined using the mechanisms defined in the SMI. 124 This memo specifies a MIB module that is compliant to the SMIv2. A 125 MIB conforming to the SMIv1 can be produced through the appropriate 126 translations. The resulting translated MIB must be semantically 127 equivalent, except where objects or events are omitted because no 128 translation is possible (use of Counter64). Some machine readable 129 information in SMIv2 will be converted into textual descriptions in 130 SMIv1 during the translation process. However, this loss of machine 131 readable information is not considered to change the semantics of the 132 MIB. 134 5. Definitions 136 MPLS-TC-MIB DEFINITIONS ::= BEGIN 138 IMPORTS 139 MODULE-IDENTITY, Integer32, Unsigned32, transmission 140 FROM SNMPv2-SMI 142 TEXTUAL-CONVENTION 143 FROM SNMPv2-TC; 145 mplsTCMIB MODULE-IDENTITY 146 LAST-UPDATED "200104101200Z" -- 10 April 2001 12:00:00 GMT 147 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" 148 CONTACT-INFO 149 " Thomas D. Nadeau 150 Cisco Systems, Inc. 151 tnadeau@cisco.com 152 Joan Cucchiara 153 jcucchiara@mindspring.com 155 Cheenu Srinivasan 156 Tachion Networks, Inc. 157 cheenu@tachion.com 159 Arun Viswanathan 160 Force10 Networks, Inc. 161 arun@force10networks.com 163 Hans Sjostrand 164 ipUnplugged 165 hans@ipunplugged.com 167 Working Group Mailing List: mpls@uu.net" 169 DESCRIPTION 170 "This MIB Module provides Textual Conventions 171 and OBJECT-IDENTITY Objects to be used by 172 MPLS networks." 174 -- Revision history. 175 REVISION "200104101200Z" -- 10 April 2001 12:00:00 GMT 176 DESCRIPTION 177 "Initial version." 178 ::= { mplsMIB 1 } -- mplsMIB To Be Assigned by IANA 180 mplsMIB OBJECT IDENTIFIER 181 ::= { transmission xxx } -- To be assigned by IANA 182 -- Since mpls is ifType: 166 183 -- we recommend xxx to be 166 185 -- The Textual Conventions defined below are organized 186 -- alphabetically 188 MplsBitRate ::= TEXTUAL-CONVENTION 189 DISPLAY-HINT "d" 190 STATUS current 191 DESCRIPTION 192 "An estimate of bandwidth in units of 1,000 bits per 193 second. If this object reports a value of 'n' then 194 the rate of the object is somewhere in the range of 195 'n-500' to 'n+499'. For objects which do not vary in 196 bit rate, or for those where no accurate estimation 197 can be made, this object should contain the nominal 198 bit rate." 199 SYNTAX Integer32 (1..2147483647) 201 MplsBurstSize ::= TEXTUAL-CONVENTION 202 DISPLAY-HINT "d" 203 STATUS current 204 DESCRIPTION 205 "The number of octets of MPLS data that the stream 206 may send back-to-back without concern for policing." 207 SYNTAX Unsigned32 (1..4294967295) 209 MplsExtendedTunnelId ::= TEXTUAL-CONVENTION 210 STATUS current 211 DESCRIPTION 212 "A unique identifier for an MPLS Tunnel. This MAY 213 represent an IpV4 address of the ingress or egress 214 LSR for the tunnel. This value is derived from 215 the Extended Tunnel Id in RSVP or the Ingress 216 Router ID for CR-LDP." 217 SYNTAX Unsigned32 218 REFERENCE 219 "1. Awduche, D., et al., RSVP-TE: Extensions to RSVP 220 for LSP Tunnels, 221 draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, 222 February 2001. 224 2. Constraint-Based LSP Setup using LDP, Jamoussi, 225 B., et al., draft-ietf-mpls-cr-ldp-05.txt, 226 February 2001." 228 MplsLabel ::= TEXTUAL-CONVENTION 229 STATUS current 230 DESCRIPTION 231 "This value represents an MPLS label. 232 The label contents are specific to 233 the label being represented. 235 The label carried in an MPLS shim header 236 (for LDP, the Generic Label) is a 20-bit number 237 represented by 4 octets. Bits 0-19 contain a 238 label or a reserved label value. Bits 20-31 MUST 239 be zero. 241 The frame relay label can be represented by either 242 10-bits or 23-bits depending on the DLCI field size and 243 the upper 22-bits or upper 9-bits must be zero, 244 respectively. 246 For an ATM label the lower 16-bits represents the VCI, 247 the next 12-bits represents the VPI and the remaining 248 bits MUST be zero." 249 REFERENCE 250 "1. MPLS Label Stack Encoding, Rosen et al, RFC 3032, 251 January 2001. 252 2. Use of Label Switching on Frame Relay Networks, 253 Conta et al, RFC 3034, January 2001. 254 3. MPLS using LDP and ATM VC switching, Davie et al, 255 RFC 3035, January 2001." 256 SYNTAX Unsigned32 (0..4294967295) 258 -- A similar TC is also used in RFC2677.txt. NOTE: since 259 -- MPLS's goal is to be any layer2 over any layer3, this 260 -- MIB makes every attempt to define a TC which would 261 -- satisfy L2 and L3 address sizes for now and in 262 -- the future. 264 MplsLdpGenAddr ::= TEXTUAL-CONVENTION 265 STATUS current 266 DESCRIPTION 267 "The value of an network layer or data link 268 layer address." 269 SYNTAX OCTET STRING (SIZE (0..64)) 271 MplsLdpIdentifier ::= TEXTUAL-CONVENTION 272 STATUS current 273 DESCRIPTION 274 "The LDP identifier is a six octet quantity 275 which is used to identify an Label Switch Router 276 (LSR) label space. 278 The first four octets encode an IP address 279 assigned to the LSR, and the last two octets 280 identify a specific label space within the LSR." 281 SYNTAX OCTET STRING (SIZE (6)) 283 MplsLdpLabelTypes ::= TEXTUAL-CONVENTION 284 STATUS current 285 DESCRIPTION 286 "The Layer 2 label types which are defined for 287 MPLS LDP/CRLDP are generic(1), atm(2), or 288 frameRelay(3)." 289 SYNTAX INTEGER { 290 generic(1), 291 atm(2), 292 frameRelay(3) 293 } 295 -- This was taken from rfc2514.txt (AtmVcIdentifier) and 296 -- modified here for MPLS. 297 -- This TC agrees with "MPLS using LDP and ATM VC Switching" 298 -- document which specifies that VC values need 299 -- to be greater than 31, or in other words, 0-31 are 300 -- reserved for other uses by the ITU and ATM Forum. 302 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION 303 STATUS current 304 DESCRIPTION 305 "The VCI value for a VCL. The maximum VCI value 306 cannot exceed the value allowable by 307 atmInterfaceMaxVciBits defined in ATM-MIB. 308 The minimum value is 32, values 0 to 31 are 309 reserved for other uses by the ITU and ATM 310 Forum. 32 is typically the default value 311 for the Control VC." 312 SYNTAX Integer32 (32..65535) 314 MplsLSPID ::= TEXTUAL-CONVENTION 315 STATUS current 316 DESCRIPTION 317 "An identifier that is assigned to each LSP and is 318 used to uniquely identify it. This is assigned at 319 the head end of the LSP and can be used by all LSRs 320 to identify this LSP. This value is piggybacked by 321 the signaling protocol when this LSP is signaled 322 within the network. This identifier can then be 323 used at each LSR to identify which labels are being 324 swapped to other labels for this LSP. For IPv4 325 addresses this results in a 6-octet long cookie." 326 SYNTAX OCTET STRING (SIZE (0..31)) 328 MplsLsrIdentifier ::= TEXTUAL-CONVENTION 329 STATUS current 330 DESCRIPTION 331 "The Label Switch Router (LSR) identifier is the 332 first 4 bytes or the Router Id component 333 of the Label Distribution Protocol (LDP) 334 identifier." 335 SYNTAX OCTET STRING (SIZE (4)) 337 MplsInitialCreationSource ::= TEXTUAL-CONVENTION 338 STATUS current 339 DESCRIPTION 340 "The entity that originally created the object in 341 question. The values of this enumeration are 342 defined as follows: 344 other(1) - This is used when an entity which has not 345 been enumerated in this textual convention 346 but which is known by the agent. 348 snmp(2) - The Simple Network Management Protocol was 349 used to configure this object initially. 351 ldp(3) - The Label Distribution Protocol was used 352 to configure this object initially. 354 rsvp(4) - The Resource Reservation Protocol was used 355 to configure this object initially. 357 crldp(5) - The Constraint-Based Label Distribution 358 Protocol was used to configure this object 359 initially. 361 policyAgent(6) - A policy agent (perhaps in combination with 362 one of the above protocols) was used 363 to configure this object initially. 365 unknown(7) -- the agent cannot discern which component 366 created the object." 368 SYNTAX INTEGER { 369 other(1), 370 snmp(2), 371 ldp(3), 372 rsvp(4), 373 crldp(5), 374 policyAgent(6), 375 unknown (7) 376 } 378 MplsPathIndex ::= TEXTUAL-CONVENTION 379 STATUS current 380 DESCRIPTION 381 "A unique identifier used to identify a specific path 382 used by a tunnel." 383 SYNTAX Unsigned32 385 MplsPathIndexOrZero ::= TEXTUAL-CONVENTION 386 STATUS current 387 DESCRIPTION 388 "A unique identifier used to identify a specific path 389 used by a tunnel. If this value is set to 0, it 390 indicates that no path is in use." 391 SYNTAX Unsigned32 393 MplsTunnelAffinity ::= TEXTUAL-CONVENTION 394 STATUS current 395 DESCRIPTION 396 "Include-any, include-all, or exclude-all constraint 397 for link selection." 398 SYNTAX Unsigned32 400 MplsTunnelIndex ::= TEXTUAL-CONVENTION 401 STATUS current 402 DESCRIPTION 403 "Index into mplsTunnelTable." 404 SYNTAX Integer32 (1..65535) 406 MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION 407 STATUS current 408 DESCRIPTION 409 "Instance index into mplsTunnelTable." 410 SYNTAX Unsigned32 (0..65535) 412 -- End of MPLS-TC-MIB 413 END 415 6. Security Considerations 417 This memo defines textual conventions and object identities for use 418 in MPLS MIB modules. Security issues for these MIB modules are 419 addressed in the memos defining those modules. 421 7. References 423 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 424 for Describing SNMP Management Frameworks", RFC 2571, April 425 1999. 427 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 428 of Management Information for TCP/IP-based Internets", STD 429 16, RFC 1155, May 1990. 431 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 432 16, RFC 1212, March 1991. 434 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 435 SNMP", RFC 1215, March 1991. 437 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 438 Rose, M., and S. Waldbusser, "Structure of Management 439 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 440 1999. 442 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 443 Rose, M., and S. Waldbusser, "Textual Conventions for 444 SMIv2", STD 58, RFC 2579, April 1999. 446 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 447 Rose, M., and S. Waldbusser, "Conformance Statements for 448 SMIv2", STD 58, RFC 2580, April 1999. 450 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 451 Network Management Protocol", STD 15, RFC 1157, May 1990. 453 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 454 "Introduction to Community-based SNMPv2", RFC 1901, January 455 1996. 457 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 458 "Transport Mappings for Version 2 of the Simple Network 459 Management Protocol (SNMPv2)", RFC 1906, January 1996. 461 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 462 Processing and Dispatching for the Simple Network Management 463 Protocol (SNMP)", RFC 2572, April 1999. 465 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 466 (USM) for version 3 of the Simple Network Management 467 Protocol (SNMPv3)", RFC 2574, April 1999. 469 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 470 "Protocol Operations for Version 2 of the Simple Network 471 Management Protocol (SNMPv2)", RFC 1905, January 1996. 473 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 474 RFC 2573, April 1999. 476 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 477 Access Control Model (VACM) for the Simple Network 478 Management Protocol (SNMP)", RFC 2575, April 1999. 480 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 481 "Introduction to Version 3 of the Internet-standard Network 482 Management Framework", RFC 2570, April 1999. 484 [MPLSArch] Rosen, E., Viswanathan, A., and R. Callon, 485 "Multiprotocol Label Switching Architecture", 486 RFC 3031, August 1999. 488 [LblStk] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., 489 Federokow, G., Li, T., and A. Conta, "MPLS Label 490 Stack Encoding", RFC 3032, January 2001. 491 label-encaps-07.txt>, September 1999. 493 [LWFRN] Conta, A., Doolan, P., Malis, A., "Use of Label 494 Switching on Frame Relay Networks Specification", 495 RFC 3034, January 2001. 497 [MLDPATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., 498 Swallow, G., Rekhter, Y., Doolan, P., "MPLS using 499 LDP and ATM VC switching", RFC 3035, January 2001. 501 [Assigned] Reynolds, J., and J. Postel, "Assigned Numbers", 502 RFC 1700, October 1994. See also: 503 http://www.isi.edu/in-notes/iana/assignments/smi- 504 numbers 506 [IPSEC] Kent, S., and Atkinson, R., "Security Architecture 507 for the Internet Protocol", RFC 2401, November 508 1998. 510 [IFMIB] McCloghrie, K., and F. Kastenholtz, "The Interfaces 511 Group MIB", RFC 2863, June 2000. 513 [ATOMMIBTC] Noto, et. al., "Definitions of Textual Conventions and 514 OBJECT-IDENTITIES for ATM Management", RFC 2514, 515 Feb. 1999 517 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RSVPTE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 521 V., Swallow, G., RSVP-TE: Extensions to RSVP 522 for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, 523 February 2001. 525 [CRLDP] Jamoussi, B., Aboul-Magd, O., Andersson, L., 526 Ashwood-Smith, P., Hellstrand, F., Sundell, K., 527 Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., 528 Feldman, N., Fredette, A., Girish, M., Gray, E., 529 Halpern, J., Heinanen, J., Kilty, T., Malis, A., 530 Vaananen, P., Constraint-Based LSP Setup using LDP, 531 draft-ietf-mpls-cr-ldp-05.txt, February 2001." 533 8. Authors' Addresses 535 Thomas D. Nadeau 536 Cisco Systems, Inc. 537 250 Apollo Drive 538 Chelmsford, MA 01824 539 Phone: +1-978-244-3051 540 Email: tnadeau@cisco.com 542 Joan Cucchiara 543 Phone: 544 Email: jcucchiara@mindspring.com 546 Cheenu Srinivasan 547 Tachion Networks, Inc. 548 Monmouth Park Corporate Center I 549 Building C, 185 Monmouth Parkway 550 West Long Branch, NJ 07764 551 Phone: +1-732-542-7750 x1234 552 Email: cheenu@tachion.com 554 Arun Viswanathan 555 Force10 Networks, Inc. 556 1440 McCarthy Blvd 557 Milpitas, CA 95035 558 Phone: +1-408-571-3516 559 Email: arun@force10networks.com 561 Hans Sjostrand 562 ipUnplugged 563 P.O. Box 101 60 564 S-121 28 Stockholm, Sweden 565 Phone: +46 8 725 5930 566 Email: hans@ipunplugged.com 568 9. Full Copyright Statement 570 Copyright (C) The Internet Society (2001). All Rights Reserved. 572 This document and translations of it may be copied and furnished 573 to others, and derivative works that comment on or otherwise 574 explain it or assist in its implementation may be prepared, 575 copied, published and distributed, in whole or in part, without 576 restriction of any kind, provided that the above copyright notice 577 and this paragraph are included on all such copies and derivative 578 works. However, this document itself may not be modified in any 579 way, such as by removing the copyright notice or references to the 580 Internet Society or other Internet organizations, except as needed 581 for the purpose of developing Internet standards in which case 582 the procedures for copyrights defined in the Internet Standards 583 process must be followed, or as required to translate it into 584 languages other than English. 586 The limited permissions granted above are perpetual and will not 587 be revoked by the Internet Society or its successors or assigns. 588 This document and the information contained herein is provided on 589 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 590 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 591 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 592 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.