Network Working Group F. Jounay Internet Draft J.L. Le Roux Category: Standards Track P. Niger Expires: August 2007 France Telecom Y. Kamite NTT Communications February 26, 2007 LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire draft-jounay-pwe3-leaf-initiated-p2mp-pw-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft will expire on August 26, 2007. Abstract This document provides a solution to extend LDP signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the leaf- initiated P2MP PW setup and maintenance. The processing for setting up a P2MP MS-PW is built on the processing for setting up a P2MP LSP with LDP. Jounay et al. Expires August 26, 2007 [Page 1] Internet Draft Leaf-initiated P2MP PW Setup February 2007 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Table of Contents 1. Terminology.................................................3 2. Preliminary Notes...........................................3 3. Introduction................................................3 4. P2MP SS-PW Setup Mechanism..................................3 5. P2MP MS-PW Setup Mechanism..................................4 5.1. P2MP MS-PW Reference Model..................................4 5.2. Overview of the P2MP MS-PW Setup............................5 5.3. P2MP FEC Element for MS-PW Setup............................5 5.3.1. P2MP GID FEC Element........................................5 5.3.2. Optional TAII Leaf Sub-TLV..................................6 5.4. Configuration...............................................6 5.5. Capability Negotiation Procedure............................6 5.6. Signaling for P2MP MS-PW....................................7 5.6.1. Label Map...................................................7 5.6.1.1. Determining one's 'upstream PE'...........................8 5.6.1.2. Egress T-PE Operation.....................................8 5.6.1.3. Branch S-PE Operation.....................................8 5.6.1.4. Ingress T-PE Operation....................................8 5.6.2. Label Withdraw..............................................8 5.6.2.1. Egress T-PE Operation.....................................8 5.6.2.2. Branch S-PE Operation.....................................9 5.6.2.3. Ingress T-PE Operation....................................9 5.6.2.4. Upstream PE Change........................................9 5.7. Using TAII Leaf Sub-TLV.....................................9 6. Security Considerations.....................................9 7. IANA Considerations........................................10 7.1. LDP FEC Type...............................................10 7.2. LDP TLV Type...............................................10 7.3. LDP Status Codes...........................................10 8. Acknowledgments............................................10 9. References.................................................10 9.1. Normative References.......................................10 9.2. Informative References.....................................11 Authors' Addresses.................................................12 Intellectual Property and Copyright Statements.....................13 Jounay et al. Expires August 26, 2007 [Page 2] Internet Draft Leaf-initiated P2MP PW Setup February 2007 1. Terminology This document uses acronyms and terminologies defined in [RFC3036], [RFC3985], [P2MP PW REQ] and [MS-PW REQ]. 2. Preliminary Notes The current version of the document does not cover: - Source-initiated unidirectional P2MP PW setup, Source-initiated grafting/pruning. This mode is described in a separate document [SOURCE INIT P2MP PW]. - The mechanism for the leaves to discover the P2MP FEC identifying the P2MP MS-PW is out of the scope of this document. - The P2MP PW Upstream Label Assignment required when the underlying layer is a P2MP LSP. This mode and detailed procedures will be described in a future version. This document describes LDP extensions for setting up P2MP MS-PW where the PW segments are supported over P2P PSN tunnels. The Working Group feedback is required on the points described above. 3. Introduction [P2MP PW REQ] describes a set of requirements for setting up a P2MP PW setup. In the MS-PW architecture, the underlying layer which supports a PW segment belonging to the PW tree may be either a P2P or a P2MP PSN tunnel. This document describes LDP extensions for setting up P2MP MS-PW where the PW segments are supported over P2P PSN tunnels. For that purpose a new P2MP GID FEC element is defined to encode MS- PW parameters. The procedures for setting up a P2MP MS-PW are built on LDP mechanisms for setting P2MP LSP [MLDP], where hops are here S- PEs and T-PEs. Therefore a leaf can join the tree by sending a Label Map associated to this FEC towards the root. The support of the underlying P2MP PSN tunnels will be described in a future version. 4. P2MP SS-PW Setup Mechanism This section will be described in a future version. Jounay et al. Expires August 26, 2007 [Page 3] Internet Draft Leaf-initiated P2MP PW Setup February 2007 5. P2MP MS-PW Setup Mechanism 5.1. P2MP MS-PW Reference Model Figure 1 describes the P2MP MS-PW reference model which is derived from [P2MP PW REQ] to support P2MP emulated services. |<-----------P2MP MS-PW------------>| Native | P2P P2P | Native Service | |<-PSN1-->| |<-PSN2-->| | Service (AC) V V tunnels V V tunnels V V (AC) | +----+ +-----+ +----+ | | |T-PE| |S-PE1|=========|T-PE| | +----+ | | 1 | | .......PW3......2.|-----------|CE2 | | | |=========| . |=========| | | +----+ | | .......PW1....... | +----+ | | | . |=========| . | +----+ | | | . | | . |=========|T-PE| | +----+ | | . | | .......PW4......3.|-----------|CE3 | +----+ | | . | | |=========| | | +----+ |CE1 |---------|.. | +-----+ +----+ | +----+ | | . | +-----+ +----+ | | | . | |S-PE2|=========|T-PE| | +----+ | | . | | .......PW5......4.|-----------|CE4 | | | . | | . |=========| | | +----+ | | . |=========| . | +----+ | | | .......PW2....... +----+ | | | |=========| . |=========|T-PE| | +----+ | | | | .......PW6......5.|-----------|CE5 | | | | | |=========| | | +----+ | +----+ +-----+ +----+ | Figure 1 P2MP MS-PW over P2P PSN tunnels Reference Model Figure 1 describes the P2MP MS-PW reference model which is extracted from [P2MP PW REQ] where the PW segments are supported over individual P2P PSN tunnels. Here in a P2MP MS-PW configuration the S- PE is responsible for switching a MS-PW from one input P2P segment to one or several output P2P segments. Referring to Figure 1 T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T- PE4 and T-PE5 are the Egress T-PEs. The S-PE S-PE1 and S-PE2 play the role of branch S-PE since they are in charge of switching the input P2P PW1 and the P2P PW2 segment to respectively the output P2P PW3,4 and the output P2P PW5,6 segments. Note that a P2MP MS-PW may obviously transit trough more than one S- PE along its path. Jounay et al. Expires August 26, 2007 [Page 4] Internet Draft Leaf-initiated P2MP PW Setup February 2007 5.2. Overview of the P2MP MS-PW Setup The P2MP MS-PW setup relies on the use of the P2MP GID FEC Element defined also in [SOURCE INIT P2MP PW]. The solution aims at setting up a unidirectional P2MP MS-PW. The principle proposed here relies on a leaf-initiated P2MP MS-PW setup. In the proposed approach the leaf is assumed to know the P2MP PW FEC which contains the source AII address and the P2MP Identifier. The procedure used for the P2MP GID FEC discovery by the leaves is out of scope of this document. The document describes the solution to setup the P2MP MS-PW in the case the PW segments are supported individually over a P2P PSN tunnel. After a negotiation procedure between Ingress T-PE/S-PE and S-PE/Egress T-PEs to verify their P2MP PW FEC capability, the Egress T-PE sends a Label Map to its upstream PE selected to reach the SAII specified in the P2MP GID FEC. At turn the S-PE carries on the signalling procedure by sending if required a new Label Map towards its next hop to reach the source SAII. In the MS-PW architecture, the hop consists either in a branch S-PE or the Ingress T-PE. Each PE receiving the P2MP FEC installs a forwarding state to map traffic into the P2MP MS-PW. 5.3. P2MP FEC Element for MS-PW Setup 5.3.1. P2MP GID FEC Element The P2MP GID FEC structure is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP GID (TBD)|C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP Id | Length | P2MP Id Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ P2MP Id Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jounay et al. Expires August 26, 2007 [Page 5] Internet Draft Leaf-initiated P2MP PW Setup February 2007 5.3.2. Optional TAII Leaf Sub-TLV A TAII Leaf sub-TLV is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| TAII Leaf Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ------------------- ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Egress T-PE sends Label Map message, it MAY optionally add the TAII Leaf sub-TLV to carry the information regarding the leaves which initiates the message. The leaves are the TAII configured on this Egress T-PE. 5.4. Configuration After configuring on each T-PE the attached AIIs, it is assumed that all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW routing table which gives for each AII as entry the "next hop" to reach that AII. This AII routing table can be filled manually or updated dynamically by means of some extended routing protocol like proposed in [DYN MS-PW]. The construction of the table is out of scope of the present document. Each PE relies on its AII PW routing table to select the next hop PE (S-PE or T-PE) to reach a given AII. 5.5. Capability Negotiation Procedure To achieve the capability negotiation the solution MUST follow the LDP capability advertisement mechanism described in [LDP CAPA]. New code points are required and MUST be defined. Jounay et al. Expires August 26, 2007 [Page 6] Internet Draft Leaf-initiated P2MP PW Setup February 2007 The PEs belonging to a given P2MP MS-PW MUST support the P2MP GID FEC Element used by LDP to setup the P2MP MS-PW. The PEs MUST also negotiate with their remote PEs the capability of supporting the PW status TLV. This negotiation is a key element in order to allow these PEs to announce some status information later on. 5.6. Signaling for P2MP MS-PW This section is directly extracted from [MLDP] and adapted to the setup of MS-PW. It defines the rules for the processing and propagation of the P2MP FEC Element for the Leaf-initiated P2MP MS-PW setup. The following notation is derived from [MLDP] and is used in the processing rules: 1. P2MP GID FEC Element : a FEC Element with SAII X, AGI Y and P2MP Id Y'. 2. P2MP PW Label Map : a Label Map message with a FEC TLV with a single P2MP GID FEC Element and Label TLV with label L. 3. P2MP PW Label Withdraw : a Label Withdraw message with a FEC TLV with a single P2MP GID FEC Element and Label TLV with label L. 4. P2MP MS-PW (or simply ): a P2MP MS-PW with SAII X, AGI Y and P2MP Id Y'. 5. The notation L' -> { ..., } on branch S- PE S means that on receiving a packet with label L', S makes n copies of the packet. For copy i of the packet, S swaps L' with Li and sends it out over interface Ii. The procedures below are organized by the role which the PE plays in the P2MP MS-PW. T-PE Z knows that it is an Egress T-PE by a discovery process which is outside the scope of this document. A T-PE is defined as an Egress T-PE if one or several leaf AIIs are configured. During the course of protocol operation, the Ingress T-PE recognizes its role because it owns the SAII of the PW tree. 5.6.1. Label Map The following lists procedures for generating and processing P2MP Label Map messages for PEs participating in a P2MP MS-PW. For the approach described here we use downstream assigned labels. Jounay et al. Expires August 26, 2007 [Page 7] Internet Draft Leaf-initiated P2MP PW Setup February 2007 5.6.1.1. Determining one's 'upstream PE' A PE Z that is part of P2MP MS-PW determines the T-LDP peer U which lies on the best path from Z to the SAII. The path selection is achieved by means of the AII PW routing table. U is Z's "Upstream PE" for . 5.6.1.2. Egress T-PE Operation An Egress T-PE Z of P2MP MS-PW determines its upstream PE U for , allocates a label L, and sends a P2MP PW Label Map to U. 5.6.1.3. Branch S-PE Operation Suppose a branch S-PE Z receives a P2MP PW Label Map from LDP peer T. Z checks whether it already has state for . If not, Z allocates a label L', and installs state to swap L' with L over interface I associated with peer T. Z also determines its upstream PE U for and sends a P2MP PW Label Map to U. If Z already has state for , then Z does not send a Label Map message for P2MP MS-PW . All that Z needs to do in this case is to update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. 5.6.1.4. Ingress T-PE Operation Suppose the Ingress T-PE Z receives a P2MP Label Map from peer T. Z checks whether it already has forwarding state for . If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP MS-PW. If Z already has forwarding state for , then Z adds "push label L, send over interface I" to the nexthop, where I is the interface associated with peer T. 5.6.2. Label Withdraw The following lists procedures for generating and processing P2MP PW Label Withdraw messages for PEs that participate in a P2MP MS-PW. 5.6.2.1. Egress T-PE Operation If an Egress T-PE Z discovers that it has no longer leaves AII belonging to the P2MP MS-PW, it SHOULD send a P2MP PW Label Withdraw Jounay et al. Expires August 26, 2007 [Page 8] Internet Draft Leaf-initiated P2MP PW Setup February 2007 to its upstream PE U for , where L is the label it had previously advertised to U for . 5.6.2.2. Branch S-PE Operation If a branch S-PE Z receives a P2MP PW Label Withdraw message from a node W, it deletes label L from its forwarding state, and sends a P2MP PW Label Release message with label L to W. If deleting L from Z's forwarding state for P2MP MS-PW results in no state remaining for , then Z propagates the P2MP PW Label Withdraw for , to its upstream T, by sending a P2MP PW Label Withdraw where L1 is the label Z had previously advertised to T for . 5.6.2.3. Ingress T-PE Operation The procedure when the Ingress T-PE of a P2MP MS-PW receives a P2MP PW Label Withdraw message are the same as for branch S-PE, except that it would not propagate the P2MP PW Label Withdraw upstream (as it has no upstream). 5.6.2.4. Upstream PE Change If, for a given PE Z participating in a P2MP MS-PW , the upstream PE changes, say from U to U', then Z MUST update its forwarding state by deleting the state for label L, allocating a new label, L', for , and installing the forwarding state for L'. In addition Z MUST send a P2MP PW Label Map to U' and send a P2MP PW Label Withdraw to U. 5.7. Using TAII Leaf Sub-TLV Section TBD The TAII Leaf sub-TLV MAY be optionally used when a leaf joins the PW tree to announce to the source that it is part from the PW tree. If this option is chosen, the Egress T-PE adds to the FEC Element this TAII sub-TLV in the Label Map message. As soon as in the source direction a Label Map is not required since for instance a S-PE already maintains a state for this MS-PW tree, the information related to the Leaf TAIIs is retrieved from the TAII Leaf sub-TLV and is propagated by means of a LDP Notification message up to the corresponding Ingress T-PE. 6. Security Considerations This section will be added in a future version. Jounay et al. Expires August 26, 2007 [Page 9] Internet Draft Leaf-initiated P2MP PW Setup February 2007 7. IANA Considerations 7.1. LDP FEC Type This document uses a new FEC element type FEC P2MP GID , from the "FEC Type Name Space" for the label Distribution Protocol (LDP RFC 3036). The following values are suggested for assignment: FEC P2MP GID : 0x83 7.2. LDP TLV Type This document uses several new LDP TLV types; IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by [RFC3036]. The following values are suggested for assignment: Sub-TLV Leaf TAII 7.3. LDP Status Codes This document uses several new LDP status codes; IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following values are suggested for assignment: Range/Value E Description Reference ------------- ----- ---------------------- --------- LDP Capabilities 8. Acknowledgments 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", January 2001. [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 Jounay et al. Expires August 26, 2007 [Page 10] Internet Draft Leaf-initiated P2MP PW Setup February 2007 9.2. Informative References [P2MP PW REQ] Jounay, F., Niger, P., Kamite, Y., Martini, L., Heron, G., Wang, L., Delord, .S, "Use Cases and signaling requirements for Point-to-Multipoint PW", Internet Draft, draft-jounay-pwe3-p2mp-pw- requirements-00.txt, February 2007 [MS-PW REQ] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", Internet Draft, draft-ietf-pwe3-ms-pw- requirements-03.txt, October 2006 [DYN MS-PW] Balus, F., Bocci, M., Martini. L, " Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf-pwe3-dynamic-ms-pw- 02.txt, October 2006 [MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands, I. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths", Internet Draft, draft-ietf-mpls-ldp-p2mp-02, June 2006 [LDP CAPA] Aggarwal, R., Aggarwal, S., Le Roux, JL., Thomas, B., "LDP Capabilities" draft-thomas- mpls-ldp-capabilities-01.txt, October 2006 [SOURCE INIT P2MP PW] Jounay, F., Niger, P., Kamite, Y., "LDP Extensions for Source-initiated Point- to-Multipoint Pseudowire" draft-jounay- pwe3-source-initiated-p2mp-pw-00.txt, February 2007 Author's Addresses Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Jounay et al. Expires August 26, 2007 [Page 11] Internet Draft Leaf-initiated P2MP PW Setup February 2007 Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: philippe.niger@orange-ftgroup.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Jounay et al. Expires August 26, 2007 [Page 12] Internet Draft Leaf-initiated P2MP PW Setup February 2007 Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jounay et al. Expires August 26, 2007 [Page 13]