From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8196.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc8196.txt (limited to 'doc/rfc/rfc8196.txt') diff --git a/doc/rfc/rfc8196.txt b/doc/rfc/rfc8196.txt new file mode 100644 index 0000000..06d8fd3 --- /dev/null +++ b/doc/rfc/rfc8196.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Liu, Ed. +Request for Comments: 8196 Huawei Technologies +Category: Standards Track L. Ginsberg +ISSN: 2070-1721 Cisco Systems + B. Decraene + Orange + I. Farrer + Deutsche Telekom AG + M. Abrahamsson + T-Systems + July 2017 + + + IS-IS Autoconfiguration + +Abstract + + This document specifies IS-IS autoconfiguration mechanisms. The key + components are IS-IS System ID self-generation, duplication + detection, and duplication resolution. These mechanisms provide + limited IS-IS functions and are therefore suitable for networks where + plug-and-play configuration is expected. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8196. + + + + + + + + + + + + + + + +Liu, et al. Standards Track [Page 1] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 + 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 4 + 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4 + 3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 6 + 3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 7 + 3.4.1. Startup Mode . . . . . . . . . . . . . . . . . . . . 7 + 3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 8 + 3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 8 + 3.4.4. Duplicate System ID Resolution Procedures . . . . . . 8 + 3.4.5. System ID and Router-Fingerprint Generation + Considerations . . . . . . . . . . . . . . . . . . . 9 + 3.4.6. Duplication of Both System ID and Router-Fingerprint 10 + 3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 12 + 3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 12 + 3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 12 + 3.5.3. Dynamic Name TLV . . . . . . . . . . . . . . . . . . 12 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 6.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + + +Liu, et al. Standards Track [Page 2] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +1. Introduction + + This document specifies mechanisms for IS-IS [RFC1195] [ISO_IEC10589] + [RFC5308] to be autoconfiguring. Such mechanisms could reduce the + management burden for configuring a network, especially where plug- + and-play device configuration is required. + + IS-IS autoconfiguration is comprised of the following functions: + + 1. IS-IS default configuration + + 2. IS-IS System ID self-generation + + 3. System ID duplication detection and resolution + + 4. IS-IS TLV utilization (authentication TLV, metrics in + reachability advertisements, and Dynamic Name TLV) + + This document also defines mechanisms to prevent the unintentional + interoperation of autoconfigured routers with non-autoconfigured + routers. See Section 3.3. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. When these words are not in ALL CAPS (such + as "should" or "Should"), they have their usual English meanings and + are not to be interpreted as [RFC2119] key words. + +2. Scope + + The autoconfiguration mechanisms support both IPv4 and IPv6 + deployments. + + These autoconfiguration mechanisms aim to cover simple deployment + cases. The following important features are not supported: + + o multiple IS-IS instances + + o multi-area and level-2 routing + + o interworking with other routing protocols + + + + + + +Liu, et al. Standards Track [Page 3] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + IS-IS autoconfiguration is primarily intended for use in small (i.e., + 10s of devices) and unmanaged deployments. It allows IS-IS to be + used without the need for any configuration by the user. It is not + recommended for larger deployments. + +3. Protocol Specification + +3.1. IS-IS Default Configuration + + This section defines the default configuration for an autoconfigured + router. + + o IS-IS interfaces MUST be autoconfigured to an interface type + corresponding to their Layer 2 capability. For example, Ethernet + interfaces will be autoconfigured as broadcast networks and Point- + to-Point Protocol (PPP) interfaces will be autoconfigured as + Point-to-Point interfaces. + + o IS-IS autoconfiguration instances MUST be configured as level-1 so + that the interfaces operate as level-1 only. + + o originatingLSPBufferSize is set to 512. + + o MaxAreaAddresses is set to 3. + + o Extended IS reachability (TLV 22) and IP reachability (TLV 135) + TLVs [RFC5305] MUST be used, i.e., a router operating in + autoconfiguration mode MUST NOT use any of the following TLVs: + + * IIS Neighbors (TLV 2) + + * IP Int. Reach (TLV 128) + + * IP Ext. Address (TLV 130) + + The TLVs listed above MUST be ignored on receipt. + +3.2. IS-IS NET Generation + + In IS-IS, a router (known as an Intermediate System) is identified by + a Network Entity Title (NET), which is a type of Network Service + Access Point (NSAP). The NET is the address of an instance of the + IS-IS protocol running on an IS. + + + + + + + + +Liu, et al. Standards Track [Page 4] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + The autoconfiguration mechanism generates the IS-IS NET as the + following: + + o Area address + + In IS-IS autoconfiguration, this field MUST be 13 octets long + and set to all 0s. + + o System ID + + This field follows the area address field and is 6 octets in + length. There are two basic requirements for the System ID + generation: + + - As specified by the IS-IS protocol, this field must be + unique among all routers in the same area. + + - After its initial generation, the System ID SHOULD remain + stable. Changes such as interface enable/disable, interface + connect/disconnect, device reboot, firmware update, or + configuration changes SHOULD NOT cause the System ID to + change. System ID change as part of the System ID collision + resolution process MUST be supported. Implementations + SHOULD allow the System ID to be cleared by a user-initiated + system reset. + + More specific considerations for System ID generation are + described in Section 3.4.5. + + + + + + + + + + + + + + + + + + + + + + + +Liu, et al. Standards Track [Page 5] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +3.3. Router-Fingerprint TLV + + The Router-Fingerprint TLV is similar to the Router-Hardware- + Fingerprint TLV defined in [RFC7503]. However, the TLV defined here + includes a Flags field to support indicating that the router is in + startup mode and is operating in autoconfiguration mode. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | | + +-+-+-+-+-+-+-+-+ Router-Fingerprint (Variable) . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 15. + + Length: The length, in octets, of the "Flags" and "Router- + Fingerprint" fields. + + Flags: 1 octet. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |S|A| Reserved | + +-+-+-+-+-+-+-+-+ + + S flag: When set, indicates the router is in "startup" mode. + + A flag: When set, indicates that the router is operating in + autoconfiguration mode. The purpose of the flag is so that two + routers can identify if they are both using autoconfiguration. + If the A flag setting does not match in hellos, then no + adjacency should be formed. + + Reserved: These flags MUST be set to zero and MUST be ignored by the + receiver. + + Router-Fingerprint: 32 or more octets. + + More specific considerations for Router-Fingerprint are described in + Section 3.4.5. + + + + + + +Liu, et al. Standards Track [Page 6] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + The Router-Fingerprint TLV with the A flag set MUST be included in + IS-IS Hellos (IIHs) originated by a router operating in + autoconfiguration mode. An autoconfiguration mode router MUST ignore + IIHs that don't contain the Router-Fingerprint TLV with the A flag + set. + + The Router-Fingerprint TLV with the A flag set MUST be included in + Link State PDU (LSP) #0 originated by a router operating in + autoconfiguration mode. If an LSP #0 is received by a router + operating in autoconfiguration mode and the LSP either does NOT + contain a Router-Fingerprint TLV or it does contain a Router- + Fingerprint TLV but the A flag is NOT set, then the LSP is flooded as + normal, but the entire LSP set originated by the sending router MUST + be ignored when running the Decision Process. + + The Router-Fingerprint TLV MUST NOT be included in an LSP with a non- + zero number and when received MUST be ignored. + +3.4. Protocol Operation + + This section describes the operation of a router supporting + autoconfiguration mode. + +3.4.1. Startup Mode + + When a router starts operation in autoconfiguration mode, both the S + and A flags MUST be set in the Router-Fingerprint TLV included in + both hellos and LSP #0. During this mode, only LSP #0 is generated + and IS or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0. + A router remains in startup mode for a minimum period of time + (recommended to be 1 minute). This time should be sufficient to + bring up adjacencies to all expected neighbors. A router leaves + startup mode once the minimum time has elapsed and full LSP database + synchronization is achieved with all neighbors in the UP state. + + When a router exits startup mode, it clears the S flag in Router- + Fingerprint TLVs that it sends in hellos and LSP #0. The router MAY + now advertise the IS neighbor and IP/IPv6 prefix reachability in its + LSPs and MAY generate LSPs with a non-zero number. + + The purpose of startup mode is to minimize the occurrence of System + ID changes for a router once it has become fully operational. Any + System ID change during startup mode will have minimal impact on a + running network because, while in startup mode, the router is not yet + being used for forwarding traffic. + + + + + + +Liu, et al. Standards Track [Page 7] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +3.4.2. Adjacency Formation + + Routers operating in autoconfiguration mode MUST NOT form adjacencies + with routers that are NOT operating in autoconfiguration mode. The + presence of the Router-Fingerprint TLV with the A flag set indicates + the router is operating in autoconfiguration mode. + + NOTE: The use of the special area address of all 0s makes it unlikely + that a router that is not operating in autoconfiguration mode will be + in the same area as a router operating in autoconfiguration mode. + However, the check for the Router-Fingerprint TLV with the A flag set + provides additional protection. + +3.4.3. IS-IS System ID Duplication Detection + + The System ID of each node MUST be unique. As described in + Section 3.4.5, the System ID is generated based on entropies (e.g., + Media Access Control (MAC) address) that are generally expected to be + unique. However, since there may be limitations to the available + entropies, there is still the possibility of System ID duplication. + This section defines how IS-IS detects and resolves System ID + duplication. A duplicate system ID may occur between neighbors or + between routers in the same area that are not neighbors. + + A duplicate system ID with a neighbor is detected when the System ID + received in an IIH is identical to the local System ID and the + Router-Fingerprint in the received Router-Fingerprint TLV does NOT + match the locally generated Router-Fingerprint. + + A duplicate system ID with a non-neighbor is detected when an LSP #0 + is received, the System ID of the originator is identical to the + local System ID, and the Router-Fingerprint in the Router-Fingerprint + TLV does NOT match the locally generated Router-Fingerprint. + +3.4.4. Duplicate System ID Resolution Procedures + + When a duplicate system ID is detected, one of the systems MUST + assign itself a different System ID and perform a protocol restart. + The resolution procedure attempts to minimize disruption to a running + network by choosing, whenever possible, to restart a router that is + in startup mode. + + The contents of the Router-Fingerprint TLVs for the two routers with + duplicate system IDs are compared. + + + + + + + +Liu, et al. Standards Track [Page 8] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + If one TLV has the S flag set (the router is in startup mode) and one + TLV has the S flag clear (the router is NOT in startup mode), the + router in startup mode MUST generate a new System ID and restart the + protocol. + + If both TLVs have the S flag set (both routers are in startup mode) + or both TLVs have the S flag clear (neither router is in startup + mode), then the router with the numerically smaller Router- + Fingerprint MUST generate a new System ID and restart the protocol. + + Fingerprint comparison is performed octet by octet starting from the + first received octet until a difference is detected. If the + fingerprints have different lengths and all octets up to the shortest + length are identical, then the fingerprint with smaller length is + considered smaller on the whole. + + If the fingerprints are identical in both content and length (and the + state of the S flag is identical), and the duplication is detected in + hellos, then both routers MUST generate a new System ID and restart + the protocol. + + If fingerprints are identical in both content and length, and the + duplication is detected in LSP #0, then the procedures defined in + Section 3.4.6 MUST be followed. + +3.4.5. System ID and Router-Fingerprint Generation Considerations + + As specified in this document, there are two distinguishing items + that need to be self-generated: the System ID and Router-Fingerprint. + In a network device, normally there are some resources that can + provide an extremely high probability of uniqueness (some examples + listed below). These resources can be used as seeds to derive + identifiers: + + o MAC address(es) + + o Configured IP address(es) + + o Hardware IDs (e.g., CPU ID) + + o Device serial number(s) + + o System clock at a certain, specific time + + o Arbitrary received packet(s) on an interface(s) + + + + + + +Liu, et al. Standards Track [Page 9] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + This document recommends the use of an IEEE 802 48-bit MAC address + associated with the router as the initial System ID. This document + does not specify a specific method to regenerate the System ID when + duplication happens. + + This document also does not specify a method to generate the Router- + Fingerprint. + + There is an important concern that the seeds listed above (except MAC + address) might not be available in some small devices such as home + routers. This is because of hardware/software limitations and the + lack of sufficient communication packets at the initial stage in home + routers when doing IS-IS autoconfiguration. In this case, this + document suggests using the MAC address as the System ID and + generating a pseudorandom number based on another seed (such as the + memory address of a certain variable in the program) as the Router- + Fingerprint. The pseudorandom number might not have a very high + probability of uniqueness in this solution but should be sufficient + in home network scenarios. + + The considerations surrounding System ID stability described in + Section 3.2 also need to be applied. + +3.4.6. Duplication of Both System ID and Router-Fingerprint + + As described above, the resources for generating a System ID / + Router-Fingerprint might be very constrained during the initial + stages. Hence, the duplication of both System ID and Router- + Fingerprint need to be considered. In such a case, it is possible + that a router will receive an LSP with a System ID and Router- + Fingerprint identical to the local values, but the LSP is NOT + identical to the locally generated copy, i.e., the sequence number is + newer or the sequence number is the same, but the LSP has a valid + checksum that does not match. The term DD-LSP (Duplication Detection + LSP) is used to describe such an LSP. + + In a benign case, this will occur if a router restarts and it + receives copies of its own LSPs from its previous incarnation. This + benign case needs to be distinguished from the pathological case + where there are two different routers with the same System ID and the + same Router-Fingerprint. + + In the benign case, the restarting router will generate a new version + of its own LSP with a higher sequence number and flood the new LSP + version. This will cause other routers in the network to update + their LSP Database (LSPDB) and synchronization will be achieved. + + + + + +Liu, et al. Standards Track [Page 10] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + In the pathological case, the generation of a new version of an LSP + by one of the "twins" will cause the other twin to generate the same + LSP with a higher sequence number -- and oscillation will continue + without achieving LSPDB synchronization. + + Note that a comparison of the S flag in the Router-Fingerprint TLV + cannot be performed, as in the benign case it is expected that the S + flag will be clear. Also note that the conditions for detecting a + duplicate system ID will NOT be satisfied because both the System ID + and the Router-Fingerprint will be identical. + + The following procedure is defined: + + DD-state is a boolean that indicates if a + DD-LSP #0 has been received. + DD-count is the count of the number of occurrences + of reception of a DD-LSP. + DD-timer is a timer associated with reception of + DD-LSPs; the recommended value is 60 seconds. + DD-max is the maximum number of DD-LSPs allowed + to be received in DD-timer interval; + the recommended value is 3. + + When a DD-LSP is received: + + If DD-state is FALSE: + DD-state is set to TRUE. + DD-timer is started. + DD-count is initialized to 1. + + If DD-state is TRUE: + DD-count is incremented. + If DD-count is >= DD-max: + The local system MUST generate a new System ID + and Router-Fingerprint and restart the protocol. + DD-state is (re)initialized to FALSE and + DD-timer is canceled. + + If DD-timer expires: + DD-state is set to FALSE. + + Note that to minimize the likelihood of duplication of both System ID + and Router-Fingerprint reoccurring, routers SHOULD have more + entropies available. One simple way to achieve this is to add the + LSP sequence number of the next LSP it will send to the Router- + Fingerprint. + + + + + +Liu, et al. Standards Track [Page 11] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +3.5. Additional IS-IS TLVs Usage Guidelines + + This section describes the behavior of selected TLVs when used by a + router supporting IS-IS autoconfiguration. + +3.5.1. Authentication TLV + + It is RECOMMENDED that IS-IS routers supporting this specification + offer an option to explicitly configure a single password for HMAC- + MD5 authentication as specified in [RFC5304]. + +3.5.2. Metric Used in Reachability TLVs + + It is RECOMMENDED that IS-IS autoconfiguration routers use a high + metric value (e.g., 100000) as default in order to allow manually + configured adjacencies to be preferred over autoconfigured. + +3.5.3. Dynamic Name TLV + + IS-IS autoconfiguration routers MAY advertise their Dynamic Name TLV + (TLV 137 [RFC5301]). The hostname could be provisioned by an IT + system or just use the name of vendor, device type, or serial number, + etc. + + To guarantee the uniqueness of the hostname, the System ID SHOULD be + appended as a suffix in the names. + +4. Security Considerations + + In the absence of cryptographic authentication, it is possible for an + attacker to inject a PDU falsely indicating there is a duplicate + system ID. This may trigger automatic restart of the protocol using + the duplicate-id resolution procedures defined in this document. + + Note that the use of authentication is incompatible with + autoconfiguration as it requires some manual configuration. + + For wired deployment, the wired connection itself could be considered + as an implicit authentication in that unwanted routers are usually + not able to connect (i.e., there is some kind of physical security in + place preventing the connection of rogue devices); for wireless + deployment, the authentication could be achieved at the lower + wireless link layer. + + + + + + + + +Liu, et al. Standards Track [Page 12] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +5. IANA Considerations + + This document details a new IS-IS TLV reflected in the "IS-IS TLV + Codepoints" registry: + + Value Name IIH LSP SNP Purge + ---- ------------ --- --- --- ----- + 15 Router-Fingerprint Y Y N Y + +6. References + +6.1. Normative References + + [ISO_IEC10589] + International Organization for Standardization, + "Information technology -- Telecommunications and + information exchange between systems -- Intermediate + System to Intermediate System intra-domain routeing + information exchange protocol for use in conjunction with + the protocol for providing the connectionless-mode network + service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, + November 2002. + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, DOI 10.17487/RFC1195, + December 1990, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange + Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, + October 2008, . + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, . + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, . + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + . + + + + +Liu, et al. Standards Track [Page 13] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +6.2. Informative References + + [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", + RFC 7503, DOI 10.17487/RFC7503, April 2015, + . + +Acknowledgements + + This document was heavily inspired by [RFC7503]. + + Martin Winter, Christian Franke, and David Lamparter gave essential + feedback to improve the technical design based on their + implementation experience. + + Many useful comments were made by Acee Lindem, Karsten Thomann, + Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang, + and Nan Wu, etc. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Liu, et al. Standards Track [Page 14] + +RFC 8196 IS-IS Autoconfiguration July 2017 + + +Authors' Addresses + + Bing Liu (editor) + Huawei Technologies + Q10, Huawei Campus, No.156 Beiqing Road + Hai-Dian District, Beijing, 100095 + P.R. China + + Email: leo.liubing@huawei.com + + + Les Ginsberg + Cisco Systems + 821 Alder Drive + Milpitas CA 95035 + United States of America + + Email: ginsberg@cisco.com + + + Bruno Decraene + Orange + France + + Email: bruno.decraene@orange.com + + + Ian Farrer + Deutsche Telekom AG + Bonn + Germany + + Email: ian.farrer@telekom.de + + + Mikael Abrahamsson + T-Systems + Stockholm + Sweden + + Email: mikael.abrahamsson@t-systems.se + + + + + + + + + + +Liu, et al. Standards Track [Page 15] + -- cgit v1.2.3