Network Working Group Jun Kyun Choi (BcN ERC) Internet Draft Dipnarayan Guha (NTU) Category: Informational Expires: January 2007 August 2006 Fast IPv6 PCE peer Advertisement using PCEMP draft-choi-pcemp-ipv6-05.txt Status of this Memo 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. 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. 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. Copyright (C) The Internet Society (2006). Abstract In this draft, we propose a guideline for an improved version of router handling procedures in RFC 2461 that allow for improved default router acquisition performance when an active IP host moves from one subnet to the other using the Path Computation Element Metric Protocol (PCEMP). Router handling procedures can be improved by a soft configuration of PCEMP support in the context of real-time data driven strategy on individual PCE nodes and this draft shows how PCEMP can support that. This draft is an informational draft that shows a guideline to specifications of modifying existing protocols to facilitate communication between LSRs and PCEs, and between a PCE and other PCEs. This can also be a guideline for mobile PCE nodes changing respective PCEDAs and thus needing fast advertisements to the corresponding LSRs and other PCE peers using IPv6 schemes. Choi, Guha Informational [Page 1] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 Table of Contents 1 Terminology ................................................. 3 2 Introduction ................................................ 4 3 Fast PCE peer advertisement ................................. 4 4 Fast processing of PCE peer solicitations ................... 4 4.1 PCE peer architecture as seen by the PCEMP protocol ..... 4 4.2 Realization of fast path computing unit architecture using PCEMP.................................................. 5 4.3 Configuration of PCE peers for fast processing of solicitations ............................................... 5 4.4 Protocol implementation considerations using PCEMP ...... 6 4.4.1 Inter-domain point-to-multipoint considerations ... 7 5 Security Considerations ..................................... 8 6 IANA Considerations ......................................... 8 7 Acknowledgements ............................................ 8 8 Intellectual Property Considerations ........................ 8 9 Normative References ........................................ 9 10 Informational References .................................... 9 11 Authors' Addresses .......................................... 10 12 Full Copyright Statement .................................... 10 Choi, Guha Informational [Page 2] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 1. Terminology 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]. This memo makes use of the following terms: 1. Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain LSPs. This entity can simultaneously act as a client and a server. Several PCEs can be deployed in a given AS. 2. Path Computation Element node (PCE Node): a network processing unit comprising of a PCE unit. This can be embedded in a router or a switch. 3. Domain: Denotes an Autonomous system (AS) within the scope of this draft. Choi, Guha Informational [Page 3] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 2. Introduction According to RFC 2461 [1] , a participating router MUST delay a response to a Router Solicitation (RS) by a random time between 0 and MAX_RA_DELAY_TIME seconds. The idea behind MAX_RA_DELAY_TIME is that if there is more than one router on the link, simultaneously transmitted responses will collide if the routers try to answer the RS immediately, and, additionally, to avoid congestion when a link comes up and all hosts on the link solicit. This can be a performance bottleneck in the case of default PCE peer acquisition for PCE nodes that are moving between PCEDAs [2]. The PCEMP protocol architecture enable the corresponding PCE peers to exchange information tags instantaneously upon discovery at any point of time. The concept of synchonization of information between PCE nodes even in the case of a change in the corresponding PCEDA can help in fast default PCE peer acquistion. 3. Fast PCE peer advertisement To enable fast response time in PCE peer solicitation processing, at most one PCE node on any given PCEDA SHOULD be allowed to respond immediately to the PCE peer solicitations sent out by PCE peers on that PCEDA. This mechanism is enabled using the SCM based fast computation techniques defined in [2]. 4. Fast processing of PCE peer solicitations 4.1 PCE peer architecture as seen by the PCEMP protocol These are the PCE unit architectures as seen by the PCEMP protocol state machines during path computation: 1. A matrix and parallel vector arithmetic unit that provides parallel data processing capabilities on the commonly used matrix and vector mathematical data types. Performance of this unit is independent of the size of the data vector under computation. This is implemented in the CC and SPC [2]. 2. The processing core that provides the ease of programming and flexibility to address changing algorithms and standards. There exists a one-to-one map from the transform computed by the core to the high-level code generated by the PCE application. This is implemented using soft memory techniques in the CC, SPC and SCM. Choi, Guha Informational [Page 4] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 3. A high-speed I/O system that allows complex, adaptive algorithms to be partitioned cost-effectively across multiple sub PCE unit blocks by providing dual ports. These ports are logically indistinguishable across the ordered pair of a data vector and the corresponding transform that is executed. These units are images of the PCE computing unit that are mapped onto the PCEMP state machines. 4.2 Realization of fast path computing unit architecture using PCEMP Concept: Iterative applications of the PCEMP DS. Two or more IDT [2] encoders separated by an interleaver (respectively CC and SPC). This structure suggests a decoding strategy based on the iterative passing of soft-computing information between two decoding algorithms. This is equivalent to dynamically partitioning the path computing engine core into sub-units that are linked together real-time based on the input data and the protocol handler. Basic Computation: Configure PCEMP DS to compute soft-decisions in terms of measures. An assigned measure is given to each branch of the IDT. 4.3 Configuration of PCE peers for fast processing of solicitations A PCE peer that is configured to provide fast solicitation processing maintains a soft decision counter and multiple IDT encoders in the form of CCs and SPCs. This might not be physical hardware, the entities may be capable of a soft configuration on individual LSRs and PCEs. From [2], we know that there are two distinct finite state machine handlings of the PCEMP protocol architecture that are configured on each participating PCE peer. They are when the PCE unit block is invoked for constantly changing data profiles within the time of goodness of fit (MAX_PCE_TIME_FIT), and the case where the PCE unit block is invoked only once for a variable data profile and the data tagged (tags) within MAX_PCE_TIME_FIT. When a PCE peer solicitation request is received, the corresponding PCE node ACK MUST be sent immediately if: CC & SPC IDT encoder count <= max tags (MAX_PCE_TIME_FIT) where max tags determine the computing potential within MAX_PCE_TIME_FIT [2]. A PCE peer SHOULD unicast the response directly to the soliciting PCE node's address, else it SHOULD schedule a multicast Router Advertisement in accordance with RFC 2461. Choi, Guha Informational [Page 5] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 When a PCE node ACK is sent, the IDT encoder count is not incremented but a corresponding flag written on the output branch measure using the z-parameter [2]. This process ensures that the IDT encoder count never exceeds max tags (MAX_PCE_TIME_FIT). If there is such a possibility, the PCEDA partitioning is recomputed by the PCE node. 4.4 Protocol implementation considerations using PCEMP |----------- (1) ------------>| | | |<-----------(2) -------------| | | |------------(3) ------------>| | | |<-----------(4) -------------| | | |------------(5) ------------>| | | |<-----------(6) -------------| PCE1 PCE2 Figure 1: PCEMP message exchanges between PCE elements For fast PCE peer advertisement, we can use PCEMP messaging for implementing router solicitation in PCEDAs using PCE techniques. Here is a sample sequence of messaging that helps in the PCE nodes maintain soft PCEMP status. Details about the protocol messages can be found in [2]. (1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the PCEMode field and the ACK REQUESTED enabled in the PCEFlag field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (PCE2) about the initiator's (PCE1) PCEMP-LOCAL-INITIATOR-ADDRESS. In this way PCE2 is initialized with the soft-memory based computation for PCEMP FSMs. (2): PCE2 receives this message and is configured with the soft-memory based path computation states. It sends back an ACK message to PCE1 with the responder's (PCE2) PCEMP-LOCAL-RESPONDER-ADDRESS (3): PCE1 sends a PCEMP Common Header with the ESTABLISH_PATH enabled in the PCEMode field, the Discovery mode set in the PCEStatus field of the Common Header and a field to indicate IPv6 addressing scheme in the PCEObject of the Common Header. It also sends a PCEMP ESTABLISH message with the following parameters: 1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be Choi, Guha Informational [Page 6] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 negotiated as discussed in [2]. In case this is not able to be negotiated, then the PCEMP ERROR message SHOULD be generated with the ERROR CODE field set to OUT OF TIME, and the PCE1 node MUST issue a fresh PCEMP ESTABLISH message with the Flag field set to STATIC. 2. In case of contention in the value of the MAX_PCE_TIME_FIT during negotiation, the node ID with the higher value wins. The other PCE node which has won contention must send a fresh PCEMP ESTABLISH message with the Flag field set to STATIC and its' own MAX_PCE_TIME_FIT value. It MUST also set the ACK requested flag in the PCEFlag of the corresponding outgoing PCEMP Common Header. The node which has lost contention SHOULD send out an ACK message along with a PCE SUBOBJECT with the MAX_PCE_TIME_FIT value obtained thus. In certain cases, the node which loses contention might send a PCEMP ERROR message with the PCEMP NEGOTIATE OBJECT informing of its status of getting a higher node ID through mobility. In such a case, when higher node ID is acquired, a PCEMP RESPONSE message MUST be sent with the PCEMP NEGOTIATE OBJECT in the message body. (4): PCE2 sends a PCEMP RESPOND message with the corresponding PCE Descriptor ID. This is matched and stored statically for the lifetime of the path computation between PCE1-PCE2 so that this ID remains static between them till the path computation is over. If the PCE Descriptor ID changes value, a PCEMP ERROR message MUST be generated with the ERROR CODE field set to PROTOCOL ERROR with its own saved PCE Descriptor ID of the wronged hop in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection mode in the PCEStatus field of the corresponding outgoing PCEMP Common Header. (5): PCE1 issues a PCEMP TEARDOWN message with the RequestType field set to CHANGE IN COMPUTATION STYLE for PCE2 to remain PCEMP enabled and the path computation state active. (6): PCE2 sends a PCEMP Common Header with the COMPUTE_PATH enabled in the PCEMode field. The PCEMP message MAY include a PCE SUBOBJECT to inform the responder (PCE1) about the initiator's (PCE2) PCEMP-LOCAL-INITIATOR-ADDRESS. 4.4.1 Inter-domain point-to-multipoint considerations The protocol implementations are followed as in the previous section, except for a few modifications. Before Step (3) as in 4.4, PCE1 needs to send a PCEMP Common Header with the COMPUTE_LSP_TYPE set in the PCEMode and the Peer-to-peer mode set in the PCEStatus. This precedes Step (3) in 4.4. The participating PCE peers thus get information that the path computation session is a point-to-multipoint one. The paths may even be aggregated for multipoint-to-multipoint TE LSP path computation in inter-domains. Choi, Guha Informational [Page 7] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 In this mode of operation, Step (6) in 4.4 is replaced with the PCE2 (or PCEn, in the more general case) sending a PCEMP Common Header with the COMPUTE_LSP_TYPE enabled in the PCEMode field. Details of inter-domain operations TBD. 5. Security Considerations The impact of the use of the PCEMP architecture is relatively much secure as the PCEDA are computed and distributed internal to the PCE unit. An increase in inter-domain information flows and the facilitation of inter-domain path establishment through PCEMP does not increase the existing vulnerability to security attacks. It should be remembered that PCEMP works by an invoked logic scheme local to each participating PCE unit, and the protocol scheme is brought into play only when there is a significant change in the data profile within the time of goodness of fit. The corresponding upper bound max tags (MAX_PCE_TIME_FIT) / MAX_PCE_TIME_FIT may be a useful metric to limit the advertisement's response rate. However, it is expected that the PCE solutions will address security issues mentioned in [Ash] in details using authentication and security techniques. 6. IANA Considerations This document makes no requests for IANA action. 7. Acknowledgements This work was supported by the BcN ITRC, Ministry of Information and Communications (MIC), Republic of Korea 8. Intellectual Property Considerations 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. Choi, Guha Informational [Page 8] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 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. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 10. Informational References [1] [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [2] Choi, J.K., and Guha, D., "Path Computation Element Metric Protocol (PCEMP)", draft-choi-pce-metric-protocol-05.txt, August 2006 (work in progress) [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in progress). [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-06.txt, January 2004 (work in progress). Choi, Guha Informational [Page 9] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006 [MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, February 2004 (work in progress). Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-05.txt, June 2006 Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-07.txt, June 2006 11. Authors' Addresses Jun Kyun Choi BcN Engineering Research Center 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Dipnarayan Guha Nanyang Technological University, Singapore Email: dg236@cornell.edu 12. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. 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. This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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 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. Choi, Guha Informational [Page 10] Internet Draft draft-choi-pcemp-ipv6-05.txt August 2006