Internet Draft Zafar Ali Cisco Systems Tomohiro Otani KDDI R&D Laboratories, Inc. Document: draft-ali-arp-over-gmpls- controlled-ethernet-psc-if-00.txt Expires: April 2006 October 2005 Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-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. 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-if-00.txt Oct. 2005 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 2. END_POINT_COMP_LINK_IP_ADDR Object.............................3 3. END_POINT_MAC_ADDR Object......................................4 4. Security Considerations........................................4 5. IANA Considerations............................................4 6. Intellectual Property Considerations...........................4 7. References.....................................................5 7.1 Normative Reference........................................5 7.2 Informative Reference......................................5 8. Author's Addresses.............................................6 9. Full Copyright Statement.......................................6 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. This information needs to be re-learned, every time the path taken by the GMPLS LSP changes (e.g., due to re-routing or re-optimization). Knowledge of IP address of the first component link in the route (at the Ingress Router) and the IP address of the last component link in the route (at the Egress router) is required to run ARP over the GMPLS LSP. If ERO is strict, and the last TE link in the route is unbundled, Ingress Router can use the computed route to find the address of the last TE link in the route. However, we cannot assume that ERO is strict or the TE link are unbundled. Similarly, the Egress router can use RRO to find the address of the first component link in the route, if the first TE link in the route is unbundled. However, use of RRO is optional. This document proposes an optional RSVP object (END_POINT_COMP_LINK_IP_ADDR) to carry the IP address of the first component link in the path in the Path message, and the IP address of Ali, Z., Otani, T. [Page 2] draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005 the last component link in the route in the Resv message. These addresses can then be use to resolve MAC addresses at the two end of the LSP. This draft also addresses latency associated with running ARP over GMPLS controlled Ethernet interfaces. 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 due to re-routing (restoration) or re-optimization, etc. Consequently This document also proposes an optional RSVP object (END_POINT_MAC_ADDR) to carry hardware addresses at the two end of the LSP, in the Path and Resv messages. If END_POINT_MAC_ADDR Object is used, END_POINT_COMP_LINK_IP_ADDR object is not required. 2. END_POINT_COMP_LINK_IP_ADDR Object The END_POINT_COMP_LINK_IP_ADDR object has a class number TBA by IANA (of type 11bbbbbb), C-Type of TBD and length of 8. The format is given below. The object can easily be extended for IPv6 addresses (TBD). Figure 1: END_POINT_COMP_LINK_IP_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Link IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. When the first component link in the route (hosted by the Ingress Router) is numbered, the Ingress LSR puts the IP address of the component link in the Path message. If this TE link is unbundled, the address is the address of the TE link in question. If the component link is unnumbered, the node id of the Ingress router is carried in the END_POINT_COMP_LINK_IP_ADDR Object. When the Egress Router receives a Path message with the END_POINT_COMP_LINK_IP_ADDR object, it adds END_POINT_COMP_LINK_IP_ADDR object to the Resv message. When the last component link in the route (hosted by the Egress Router) is numbered, the Egress LSR puts the IP address of the component link in the Resv message. If this TE link is unbundled, the address is the address of the TE link in question. If the component link is unnumbered, the node id of the Ingress router is carried in the END_POINT_COMP_LINK_IP_ADDR Object. Ali, Z., Otani, T. [Page 3] draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005 3. 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' MAC Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. The Ingress LSR puts the MAC address of the first component link in the route (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 the last component link in the route, which is host by it (Egress Router). 4. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC2205] remain relevant. 5. IANA Considerations Type of RSVP Object proposed in this document needs to be assigned. 6. Acknowledgements The author would like to acknowledge close discussions on this topic with Adrian Farrel and Dan Tappan. 7. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Ali, Z., Otani, T. [Page 4] draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005 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. 8. References 8.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. [BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf- mpls-bundle-06.txt, K. Kompella, et al, January 2003. [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. 8.2 Informative Reference [ARP] "An Ethernet Address Resolution Protocol ", RFC 826, 1982. Ali, Z., Otani, T. [Page 5] draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005 9. 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 Kamifukuoka Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp 10. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 6]