Internet Draft Zafar Ali Cisco Systems Tomohiro Otani KDDI R&D Laboratories, Inc. Document: draft-ali-arp-over-gmpls- controlled-ethernet-psc-if-02.txt Expires: April 2006 October 2006 Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.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. Abstract This document outlines some issues with the use of ARP over GMPLS controlled Ethernet router-to-router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC GMPLS core. The document also proposes solutions accordingly. Conventions used in this document Ali, Z., Otani, T. [Page 1] draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt Oct. 2006 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction...................................................2 3. END_POINT_MAC_ADDR Object......................................3 4. Security Considerations........................................3 5. IANA Considerations............................................4 6. Intellectual Property Considerations...........................4 7. References.....................................................4 7.1 Normative Reference........................................4 7.2 Informative Reference......................................5 8. Author's Addresses.............................................5 9. Full Copyright Statement.......................................5 1. Introduction This draft address the scenario where edge routers are connected via a non-Ethernet switch capable GMPLS core, e.g., FSC or LSC core. Furthermore, the interfaces between the router and the optical device (OXC) are Ethernet. When an LSP Path is established between the Ingress Router to Egress Router, Ethernet interface at the two routers comes up. However, before this LSP (or interface) can forward any IP traffic, MAC address of the remote router needs to be learned. End-point MAC address needs to be re-learned, every time the path taken by the GMPLS LSP changes (e.g., due to re-routing or re- optimization). This introduces latency that is at least equal to the round trip delay. Such latency adds to the traffic switchover delay and consequently traffic loss for 1:1 protected LSP without extra traffic, or when LSP route changes due to re-routing (restoration) or re-optimization, etc. Interop issues in learning end-point MAC address using ARP are also found among vendors at various Interop events/ testing efforts. This is because different vendors use different IP address for ARP resolution. Some LSR vendor uses the address of the TE link at the end-point, while others adapt to use tunnel interface address for ARP. When both end-point TE link address and tunnel interface addresses are unnumbered, the ARP needs to be performed using Ali, Z., Otani, T. [Page 2] draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt Oct. 2006 loopback addresses. Some routers do not reply to ARP request sent to a loopback address. Issue with the use of IP address for ARP can be resolved by agreeing on use of IP address and by requiring ARP using Loopback addresses. However, issue associated with ARP latency and traffic loss for 1:1 protected LSP without extra traffic, or when LSP route changes due to due to re-routing (restoration) or re-optimization, etc. could not be addressed when we rely on ARP to learn end-point MAC address. Consequently, this document proposes use of RSVP object (END_POINT_MAC_ADDR) to carry hardware addresses at the two end of the LSP, in the Path and Resv messages. 2. END_POINT_MAC_ADDR Object The END_POINT_MAC_ADDR object has a class number TBA by IANA (of type 11bbbbbb), C-Type of TBD and length of 28. The format is given below. Figure 1: END_POINT_MAC_ADDR Object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | End Point’s MAC Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. The Ingress LSR puts the MAC address of its outgoing physical interface (this is the first component link in the route, which is hosted by the Ingress Router) in the Path message. When the Egress Router receives a Path message with the END_POINT_MAC_ADDR object, it adds END_POINT_MAC_ADDR object to the Resv message and puts the MAC address of incoming physical interface (this is the last component link in the route, which is host by the Egress Router). 3. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] remain relevant. Ali, Z., Otani, T. [Page 3] draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt Oct. 2006 4. IANA Considerations Type of RSVP Object proposed in this document needs to be assigned. 5. Acknowledgements The author would like to acknowledge close discussions on this topic with Adrian Farrel and Dan Tappan. 6. 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. 7. References 7.1 Normative Reference [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, Braden, et al, September 1997. [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, RFC 3209, December 2001. [RFC 4201] "Link Bundling in MPLS Traffic Engineering", K. Kompella, et al, RFC 4202, October 2005. Ali, Z., Otani, T. [Page 4] draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt Oct. 2006 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, L. Berger, et al, January 2003. [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- TE) Extensions", RFC 3473, L. Berger, et al, January 2003. [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella, Y. Rekhter, January 2003. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, S. Bradner, March 1997. 7.2 Informative Reference [ARP] "An Ethernet Address Resolution Protocol ", RFC 826, 1982. 8. Author's Addresses Zafar Ali Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8 Canada. Phone: (613) 889-6158 Email: zali@cisco.com Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino-shi Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp 9. Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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. Ali, Z., Otani, T. [Page 5]