Transcript ccamp-7
Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-04.txt Zafar Ali ([email protected]) Hassan Sheikh ([email protected]) Tomohiro Otani ([email protected]) 68th IETF, Prague, March 2007 1 Agenda • How comments are addressed? • Summary of proposed recommendations. • Next Steps. 68th IETF, Prague, March 2007 2 Change History • Summary of the minutes of CCAMP meeting at IETF 67 (http://www3.ietf.org/proceedings/06nov/minutes/ccamp.html) Agreed on defining a common addressing scheme for ARP Resolution. No extension to RSVP-TE for this purpose. • The version 03 was updated accordingly. • Version 04 addresses comments received from CCAMP meeting at IETF 68. 68th IETF, Prague, March 2007 3 Scope of the Draft Non-Ethernet IF LSP 10.1.1.2 Router 1 10.1.1.3 OXC2 Ethernet IF Non-Ethernet IF Non-Ethernet IF OXC1 OXC3 Non-Ethernet GMPLS Network Ethernet IF Router 2 OXC4 • Issues with the use of ARP over GMPLS controlled Ethernet router-torouter (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC GMPLS core. • In this case, GMPLS LSP is using Ethernet encoding. • 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. 68th IETF, Prague, March 2007 4 ARP resolution on GMPLS LSP using Eth framing GMPLS LSP 192.168.1.1/29 192.168.1.2/29 Eth link ARP reuest OXC Eth link Router # 2 Router # 1 ARP response Send L3 packet to router # 2 Step # 1 - Step # 2 - Step # 3 - Step # 4 - Step # 5 - Router # 1 needs to send packet to Router # 2. The following information is required: (1) SRC IP address (2) DST IP address (3) SRC MAC and (4) DST MAC. Router # 1 knows (1), (2) and (3) but does not know (4). It needs to associate L3 Network Layer with L2 data link layer address, i.e., need DST MAC address to send the packet to Router #2. Router # 1 sends out an ARP query requesting the MAC address corresponding to the IP address 192.168.1.2. Router # 2 responds with the MAC address as the IP address is local to router # 2 Router # 1 now knows (1), (2), (3) and (4) from step # 1. It can send L3 traffic to router # 2 now 68th IETF, Prague, March 2007 5 Inter-op Issues in resolving ARP 192.168.1.1/29 LSP 10.1.1.2 Router 1 10.1.1.3 OXC2 10.1.1.1 192.168.1.2/29 OXC1 OXC3 Non-Ethernet GMPLS Network 10.1.1.4 Router 2 OXC4 • Inter-op issues in resolving ARP among vendors found at various public events/ private testing efforts. Some routers send ARP request for the address of the TE link at the end-point. Some LSRs send ARP request using the tunnel IF address at the end-points. Some vendors do not reply to ARP request sent to the loopback address. Also, should the loopback interface address from optical or packet instance be use. • Solution: At IETF 67 meeting we agreed to define a common addressing scheme for ARP Resolution. • An LSR SHOULD use address from packet network (and not the TE link address of the optical link) for ARP request. 68th IETF, Prague, March 2007 6 ARP Round-trip Delay E1/0 Router 1 OXC2 LSP1 Non-Ethernet GMPLS Network Working LSP OXC3 LSP2 E2/0 OXC1 Protecting LSP E1/0 OXC4 E2/0 Router 2 • ARP round-trip delay before traffic can be forwarded to the protecting LSP, when doing a cutover to a "cold standby" LSP (e.g., 1:1 Case). In 1:1 or 1:N protection without extra traffic, the protecting LSP cannot carry any traffic until the traffic is switchover. • End-point MAC address needs to be re-learned once the ARP cache entries time-out, or every time the path taken by the GMPLS LSP changes (e.g., due to re-routing or re-optimization). • The Round Trip latency implies traffic loss (i.e., no O(50 msec) guarantees). • Solution: Assign stable virtual MAC address that can share with the both Ethernet IF (protection and working). 68th IETF, Prague, March 2007 7 Next Steps • We need to do a revision based on the comments received. 68th IETF, Prague, March 2007 8 Backup Slides 68th IETF, Prague, March 2007 9 Why not use gratuitous ARP ?? GMPLS LSP 192.168.1.1/29 192.168.1.2/29 Eth link ARP reuest OXC Eth link Router # 2 Router # 1 ARP response • Gratuitous ARP could mean both gratuitous ARP request or gratuitous ARP reply. Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826) but could be used in some cases. A gratuitous ARP request is an Address Resolution Protocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff. • Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts. • Pros – Automatic Detection of MAC address of the remote node (in p2p) and/or link up down event. • Cons – For GMPLS we have seen that this mechanism is unreliable because: • Transmitted once only so if missed – will not be sent again. We have seen cases in our testing where one side know the MAC address of the other side but the other side does not know anything as it missed out the gratuitous ARP sent to it. • Issue when ARP cache times out e.g. in case there is no activity on the data link. P&R protection LSP is the perfect example of a GMPLS application where this is seen. 68th IETF, Prague, March 2007 10