Network Working Group Jun Kyun Choi (ICU) Internet Draft Dipnarayan Guha (ICU) Category: Informational Expires: April 2005 October 2004 Fast IPv6 PCE peer Advertisement using PCEMP draft-choi-pcemp-ipv6-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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. 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. J.K.Choi, D.Guha Informational [Page 1] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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 5 Security Considerations ..................................... 6 6 IANA Considerations ......................................... 7 7 Acknowledgements ............................................ 7 8 Intellectual Property Considerations ........................ 7 9 Normative References ........................................ 8 10 Informational References .................................... 8 11 Authors' Addresses .......................................... 9 12 Full Copyright Statement .................................... 9 J.K.Choi, D.Guha Informational [Page 2] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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. J.K.Choi, D.Guha Informational [Page 3] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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]. J.K.Choi, D.Guha Informational [Page 4] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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. 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. J.K.Choi, D.Guha Informational [Page 5] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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. 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. 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. J.K.Choi, D.Guha Informational [Page 6] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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 in part by the Korea Science and Engineering Foundation (KOSEF) through the Ministry of Science and Technology (MOST) and the Institute of Information Technology Assessment (IITA) through the 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. 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. J.K.Choi, D.Guha Informational [Page 7] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 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-00.txt, October 2004 (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). [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). [Ash] Farrel, A., Vasseur, JP., and Ash, J., "Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, September 2004 (work in progress) J.K.Choi, D.Guha Informational [Page 8] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004 11. Authors' Addresses Jun Kyun Choi Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Dipnarayan Guha Information and Communications University (ICU) 103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea Phone: +82-42-866-6282 Email: dip@icu.ac.kr 12. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. J.K.Choi, D.Guha Informational [Page 9] Internet Draft draft-choi-pcemp-ipv6-00.txt October 2004t