CCAMP Working Group Jaihyung Cho INTERNET DRAFT ETRI Expires: July 2005 February 2005 Use of ARP and Flood Routing Technique for LSP setup in ECPN Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 docu- ments 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. This Internet-Draft will expire on February 2005. Abstract In this memo, we first discuss some weaknesses of proposals employing RSVP in local network, such as RFC2814, 2815, 2816, and propose extension of ARP (Address Resolution Protocol) and [LSE] technique for solution to provide QoS in Ethernet based Customer Premise Network (ECPN). Framework architecture of LSE (Label Switched Ethernet) as a method of GMPLS implementation for Ethernet is described in [LSE]. ARP is proposed for integrated signaling and routing protocol in ECPN. This document describes overview of ARP extension, procedure for label negotiation and method for QoS routing. Major features of this ARP extension are; support for label switching, incorporation of routing function, compatibility with legacy Ethernet and enhanced security. Jaihyung Cho Expires July 2005 [Page 1] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 Table of Contents: 1. Introduction................................................2 2. Overall Mechanism of LSE and ARP Signaling .................5 3. Flood Routing Technique ....................................8 4. Constraint Based Routing .................................12 5. Discussion on Overhead of Flooding ........................12 6. Security Considerations....................................13 7. References.................................................13 Appendix A Example Values of ARP Messages in Figure 1 ......14 Author's Addresses............................................17 1. Introduction While there has been significant progress in Quality of Service (QoS) architectures for provider networks, mechanism for end stations to utilize such service is necessary in order to guarantee end-to-end service delivery. RFC2998 stresses this issue and describes an architecture mapping IntServe and DiffServe regions. In the RFC, RSVP is proposed for explicit signal that deliver user request in around customer premise and aggregate the flows in core network. In accordance with the discussion, RFC2816 outlines a functional model for supporting RSVP in shared and switched LAN infrastructure. The architecture does not require modification in features defined in IEEE 802 specification but simply define mappings of the various IETF Integrated Services onto priority schemes in 802 LANs. Detail of the extension of RSVP, and SBM (Subnet Bandwidth Manager) protocol for admission control and bandwidth management are described in RFC2814 and RFC2815. While the work demonstrated an RSVP implementation over LAN media, weakness of RFC2816 is complexity. For example, the method requires all the heaviness analogous to routers in addition to basic operation of RSVP, such as loop-detection, L2/L3 address mapping, access control and service class translation, master node election and so on. As stated in the RFC, " íª It essentially does what RSVP already does at Layer 3". If there is only a little difference with layer-3 RSVP, it will be better to use low-cost layer-3 switches rather than complex layer-2 switches with modified RSVP. Another drawback is vulnerability from malicious attack. RFC2816 assumes end stations are trusted to adhere to their negotiated contracts at the inputs to the network. This assumption is not valid in open, public environment such as campus network or Ethernet based access network. Users may manipulate VLAN tag, IP headers can be encrypted and port numbers can be dynamically changed. It is so easy to abuse service class and disturb traffic flows. Secure and reliable method for identification of premium service flows is important in such environment. Jaihyung Cho Expires July 2005 [Page 2] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 Operational difficulty is the other problem. The RFC requires manual configuration of IP addresses and MAC addresses. Apart from scarcity of IP and MAC addresses, most residential users or small- network owners will not have the professional knowledge of network. Furthermore, it requires end users understand complex parameters of RSVP, such as Flowspec, Tspec, which may not be necessary at all times. It is noted that ISPs have to spend enormous operation cost for supporting individual customers. If customers have difficulty in configuring their residential network or office network, it will be more burdens to service providers and application developers. Although some professional technicians may like the flexibility and sophistication of RSVP, it will not be so desirable to most ordinary users. To the last point, RFC2814 requires ubiquitous deployment of common signaling entity in all user terminals and network device. Unfortunately, local switch manufacturers do not support it for reasons above and immaturity of application market. Lack of user capability for signaling impedes emergence of new commercial service and evolution of QoS technique. In order to facilitate fast proliferation of QoS applications, signaling protocol must not expect receiving terminal is reciprocal. In other words, source terminal must be able to negotiate service even when the receiving party is not conformant. The network must be able to provide service although deployment of new service is partial. The ARP signaling presented here, along with Label Switched Ethernet (LSE) technique described in [LSE], overcomes the shortcomings discussed above. Contrast to approaches that use RSVP for application signal, terminals and Ethernet switches use ARP (Address Resolution Protocol) for negotiating resources and establishing LSP. Some distinct features of ARP signaling are listed below : - Support for MAC address swapping : The modified ARP is primarily designed for passing label information of MAC address format and establishing LSP between terminals and Ethernet switches. The role is similar to [LDP] or [RSVP-TE] in MPLS network, however, this protocol is dedicated for Ethernet. - Incorporates routing : The most distinctive feature of this extension is that ARP protocol carries out routing function using novel flood routing technique. Ethernet switches establish LSP via shortest available path without relying on pre-established routing database or spanning tree algorithm. It does not have typical weaknesses of other routing algorithms such as looping, traffic concentration or global update on failure. - Non-reciprocal : Contrast to RFC2814, the proposed method does not require bilateral implementation of signaling entity in both communicating terminals. Ethernet switches of this implementation will do best to meet the bandwidth requirement of real-time traffic Jaihyung Cho Expires July 2005 [Page 3] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 and provide preferential service than besteffort traffic. - Compatibility with legacy Ethernet : The proposed method allows interconnection with legacy terminals and switches in any configuration. QoS applications may use extended feature of ARP while other besteffort applications are not affected at all. - Low operational overhead : Basic operation mode of this protocol does not require pre-configuration of switches, while network managers may configure sophisticated functions to impose policy or access control. - Scalability : This extension allows large-scale Ethernet sub- divided and structured according to IP address hierarchy. Border switches of sub-division may block internal broadcast and selectively relay ARP messages. Since ARP incorporates routing function, Ethernet switches have the scalability comparable to routers. - Traffic Engineering : In LSE network, besteffort and real-time flows are transmitted via LSPs. Hence, Network operators are able to control traffic flows in fine granularity using LSPs. 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]. Jaihyung Cho Expires July 2005 [Page 4] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 2. Overall Mechanism of LSE and ARP Signaling Framework architecture of LSE (Label Switched Ethernet) as a method of GMPLS implementation for Ethernet is described in [LSE]. Readers are advised to have knowledge of MAC address swapping explained in [LSE]. In LSE, 48bits of Ethernet address in MAC header is used for labels. Ethernet switches supporting this technique identify flows of different applications according to MAC addresses. LSE switches allocate MAC addresses when they receive ARP request/reply messages and pass the label information using ARP. Figure 1 below shows format of ARP message described in RFC826. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Ethernet Address (6byte=broadcast MAC) | | +-------------------------------+ | | | +-------------------------------+ + | Source Ethernet Address (6byte) | +-------------------------------+-------------------------------+ | Length/Type (=ARP) | L2 Address Type (=Ethernet) | +-------------------------------+---------------+---------------+ | L3 Address Type (=IPv4) |L2 Leng (=0x06)|L3 Leng (=0x04)| +-------------------------------+---------------+---------------+ | OP Code (=Req/Rpy/Rarp...) | | +-------------------------------+ + | Sender Ethernet Address (6byte) | +---------------------------------------------------------------+ | Sender IPv4 Address (4byte) | +---------------------------------------------------------------+ | Target Ethernet Address (6byte) | | +-------------------------------+ | (%used for LSE) | Target IPv4 Address | +-------------------------------+-------------------------------+ | (4byte) | | +-------------------------------+ | | | | Padding (or FCS) | | | | | +---------------------------------------------------------------+ Figure 1 ARP message format According to RFC826, the message format of Figure 1 is used when source terminal broadcasts ARP request. Target terminal also uses Jaihyung Cho Expires July 2005 [Page 5] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 the same format when it responds with ARP reply. Since identical format is used in both directions, some information field is meaningless depends on message type (i.e., OP Code). For example in the case of ARP request, source Ethernet address in the header and sender Ethernet address in the message body are redundant information. 6 bytes of Target Ethernet Address (TEA) field is unused in ARP request because only the target terminal can fill the information. The ARP extension uses such fields for controlling ARP broadcast and LSP establishment. The procedure for LSP setup and swapping of MAC address is described in Figure 2. Terminal Switch Switch Terminal [Ea]==============[S1]=================[S2]==============[Eb] ARPreq(SA=Ea,TA=? ) --------> --ARPreq(SA=FF,TA=? )--> ------> ARPreq(SA=FF,TA=? ) <------ ARPrpy(SA=Eb,TA=FF) <--ARPrpy(SA=Lc,TA=FF)-- ARPrpy(SA=La,TA=Ea) <------- ............................................................ DATA(SA=Ea,DA=La) -> DATA(SA=Lb,DA=Lc) -> DATA(SA=Ld,DA=Eb) DATA(SA=La,DA=Ea) <- DATA(SA=Lc,DA=Lb) <- DATA(SA=Eb,DA=Ld) Figure 2 ARP procedure and frame transmission In Figure 2, it is assumed that a QoS application in source terminal Ea is requesting a connection of certain bandwidth requirement to underlying layer. This triggers source terminal Ea transmits ARP request in order to resolve IP-to-Ethernet address mapping of target destination terminal Eb. The bandwidth requirement is encoded in TEA field of the ARP message because the field is not used in legacy ARP request. The addresses of frame header are (DA=broadcast address, SA=Ea). S1 and S2 are LSE switches that have instances of extended ARP in control plane. Note that ARP uses reserved Length/Type code (=0x0806) in frame header. Therefore, LSE switches are able to distinguish ARP messages from other Ethernet frames, and intercept (i.e. snoop) ARP messages for processing in control plane. In the example above, S1 is the first LSE switch that intercepts ARP request. Jaihyung Cho Expires July 2005 [Page 6] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 S1 overwrites Source Ethernet Address field and Sender Ethernet Address field of the ARP request message to a multicast address reserved for this protocol, hence the addresses of frame header become (DA=broadcast address, SA=multicast address). This masquerading is necessary in order to prevent ARP reply message being forwarded to source node directly by non-LSE switches. It also gives an effect of concealing physical address of source terminal, thus provides good security. The first-hop LSE switch, S1, encodes session identification information in the TEA field. S1 broadcasts the modified ARP request, and other LSE switches relay the message. As a result, the message finally reaches target terminal Eb. Target terminal Eb may or may not have capability for negotiating resources according to this protocol. When Eb is LSE conforming, Eb may reply a negative message explicitly, such as ARP error, or silently ignore the message if the request is not acceptable. Otherwise, any ordinary response with ARP reply will be regarded as consent to establish LSP. For this reason, source terminals of this protocol are able to establish LSP with any terminal regardless of receiver capability of same protocol. Therefore, ubiquitous deployment of this extended feature is not prerequisite. Terminal Eb records its physical address 'Eb' in Sender Ethernet Address field and IP address in Sender IPv4 Address field. Target IPv4 Address is the IP address of Ea, however, Target Ethernet Address (TEA) becomes multicast address because reserved multicast address was used in Source Ethernet Address field in ARP request. Addresses of frame header become (DA=multicast address, SA=Eb). Eb transmits ARP reply to S2. S2 receives the ARP reply and allocates two labels, 'Lc' and 'Ld' for each side of interface. Note that the labels, 'Lc' and 'Ld', are reusable MAC addresses chosen out of address pool reserved for LSE protocol (see [LSE] for detail). S2 configures swapping entries in MAC lookup table so that destination address 'Lc' of any incoming Ethernet frame will be translated to 'Eb' when it is forwarded to terminal Eb. S2 records the label 'Lc' in Sender Ethernet Address field and passes the ARP reply to upstream neighbor S1. Upon receiving the ARP reply, S1 also allocates two new labels, 'La' and 'Lb', and configures swapping entries in MAC table. S1 overwrites Sender Ethernet Address and Source Ethernet Address of the message to 'La', and retrieves Destination Ethernet Address and Target Ethernet Addressto original physical address of terminal Ea. Hence, addresses of frame header become (DA=Ea, SA=La). When Ea receives the modified ARP reply message, Ea will believe that 'La' is the physical address of destination terminal Eb, and configures IP-Ethernet mapping entry of Eb in ARP cash. As a result, any IP packet transmitted to Eb will use the MAC address 'La'. Detail of message values at each stage of ARP procedure is explined in Jaihyung Cho Expires July 2005 [Page 7] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 appendix A. Label switched frame transmission procedure is described below of dotted line in Figure 1. The initial MAC header that Ea creates will be (DA=La, SA=Ea). When S1 receives the frame, S1 performs normal MAC table lookup using the destination address La and identifies that La is the label that S1 assigned for this flow. S1 swaps MAC addresses in the header from (DA=La, SA=Ea) to (DA=Lc, SA=Lb). Recall that Lb is the address S1 assigned on output interface and Lc is the address S2 informed using ARP reply. When S2 receives this frame, S2 also swaps MAC addresses from (DA=Lc, SA=Lb) to (DA=Eb, SA=Ld) and forwards the frame to destination terminal Eb. No modification of interface hardware is required in source and destination terminals. Detail of address swapping technique is discussed in [LSE]. It is re-stated that tradeoff of swapping operation compared to typical Ethernet switching is improved QoS and protection. Flow identification is an essential element in providing QoS. The proposed LSE technique enables Ethernet switches distinguish application flows only using MAC address. This simplifies hardware architecture to implement per-flow differentiated service, because Ethernet switches do not need to check additional fields, such as VLAN tag, IP header and TCP header. Improved protection from intrusion is additional benefit because physical address of user terminal is not exposed. 3. Flood Routing Technique The unique feature of ARP signaling is ARP incorporates routing capability that it finds optimum path satisfying QoS requirement. It is an integrated solution that merges address resolution, route selection and label distribution in one mechanism. Contrast to IP routing protocols, this method does not require any pre- configuration such as node or link numbering, hence reduces operational overhead. This algorithm also minimizes dependency to inefficient spanning tree algorithms. The rationale behind the flood routing algorithm is survival of the fittest. LSE nodes produce multiple copies of ARP messages to explore unknown routes. As the ARP messages propagate network, each message experience different difficulty in progressing network according to network load, and record the difficulty information. Intermediate nodes evaluate the information carried in message and select the fittest one for duplication. As a result, only the message that traversed via most appropriate path is accepted as final winner, and the information of the path explored by the message is used for establishing LSP or routing database. The basic action of flooding is described in figure 3 below. When a Jaihyung Cho Expires July 2005 [Page 8] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 node receives an ARP request from a source terminal, the node broadcasts duplicates of the ARP message to all output interfaces except the one from which the message was received. Neighboring nodes that receive the message also repeat the copy-and-broadcast action blindly, as a result, network will soon be saturated by duplicates of the messages if there is no control method. In this ARP extension, 6bytes of TEA (Target Ethernet Address) field is used for encoding information necessary to control flooding. Figure 4 describes the TEA format. ___ ARP(m=7) / \ ARP(m=15) ------------>| S2 |--------------> / [cost=8] \___/ / [min=15] ARP(m=9) ___ / ___ -------------> ARP(m=3) / \ / ARP(m=7) / \ / ----------->| S1 |---------------->| S3 |----ARP(m=9)--> [cost=4] \___/ \ [cost=2] \___/ \ [min=7] \ [min=9] -------------> \ ___ ARP(m=9) \ ARP(m=7) / \ ------------>| S4 |--------------> [cost=9] \___/ ARP(m=16) [min=16] Figure 3 Basic Flooding Action In figure 4, the first 16 bits of Timestamp is used for identification of flood associated with this session. Combined with Sender IPv4 address (i.e., source terminal address), the pair of (IPv4 address, Timestamp) uniquely identifies ARP message. Only the first-hop LSE switch that receives ARP request directly from source terminal is entitled to set the Timestamp, and overwrites the Source Ethernet Address to a reserved multicast address. Other LSE nodes must not alter the Timestamp if the Source Ethernet Address is the multicast address. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (16bit) | Metric (16bit) | +---+---------------------------+-------------------------------+ |FO | Bandwidth (14bit) | +---+---------------------------+ Figure 4 Flood Control Information Encoding in TEA Field Following the Timestamp, 16 bits of Metric field indicates difficulty of path that ARP request has traversed. LSE nodes add up Jaihyung Cho Expires July 2005 [Page 9] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 cost of input link to the metric value. The link cost is a locally measured value of current load that reflects various criteria of traffic state such as link utilization, frame loss or number of LSPs. High metric value implies bad path to avoid. Figure 3 shows example that metric values are computed at each node. In figure 3, received metric value of ARP request at S1 is 3 and cost of input link is 4, hence the metric value becomes 7 (=3+4). Metric value of the ARP request is updated to 7. The information of ARP message and metric value, denoted by [min=7] in the figure, is stored in S1. S1 broadcasts the message through all output links. Neighboring nodes, S2, S3 and S4, receive duplicates of ARP request. Each node updates metric value according to cost of input link and repeats the copy-and-broadcasting action described above. Since the ARP messages traversed links of different cost, metric values of output messages after the nodes become different. Among the messages of different metrics, only the lowest one will be chosen to produce offspring by intermediate nodes. This selection procedure is described in figure 5 below. ARP(m=4) ARP(m=9) -------------- ----------- [cost=6] \ [cost=1] \ \ \ x ___ x ___ ARP(m=2) / \ ARP(m=6) / \ ARP(m=8) ----------------->| S5 |--------------->| S6 |-----------> [cost=4] \___/ [cost=2] \___/ x [min=6] x [min=8] / / ARP(m=8) / ARP(m=5) / -------------- ----------- [cost=2] [cost=5] Figure 5 Selection process of the lowest metric ARP request In figure 5, it is assumed that S5 receives multiple ARP requests traversed via different routes. Among the messages, S5 selects message of the lowest metric value (i.e., m=2, cost=4, thus [min=6]) for duplication. Other messages of higher metric value are discarded. S6 also receives ARP requests from neighboring nodes, however, only the one received from S5 has the lowest metric value (i.e., m=6, cost=2, thus [min=8]). Therefore the message is selected to propagate the network. Note that network nodes simply repeat select-and-broadcast action blindly, however the end result is refining routes that only the message traversed via most appropriate path survives and reaches final target. There can be multiple available paths between source and destination terminals, however, the most lightly loaded path is Jaihyung Cho Expires July 2005 [Page 10] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 chosen by flooding for establishment of LSP. For example in figure 6, there are three available paths between terminals Ea and Eb. S5 receives ARP requests of different metric values from S2, S3 and S4. Among the presented paths, Ea->S1->S3->S5->Eb is the lightly loaded path because metric value of the ARP request is only 5 while others are 10 and 16. Hence, S5 selects the ARP request received from S3 and broadcasts it. Target terminal Eb responds with ARP reply as typical ARP procedure. Upon receiving the ARP reply, S5 configures LSP as the procedure described in section 2. S5 encodes label information in ARP reply and passes it to S3 because ARP request of the lowest metric value was received from S3. S3 also configures LSP and forwards ARP reply to S1 because S1 is the only node that passed ARP request. Finally, S1 configures LSP and informs a MAC address that Ea will use for this LSP. As a result, LSP is established via shortest path in local network without relying on pre-established routing database or complex routing algorithm. Detail of other issues, such as LSP keep-alive, termination and failure recover, are not presented in this introductory draft. +----+ Source Terminal | Ea | +----+ ARPrpy ^ | ARPreq | | |_V ARPreq(m=1) / \ ARPreq(m=1) <--------| S1 |---------> / \___/ \ / ^ | \ / ARPrpy | | ARPreq(m=1) \ ___/ |_V \___ / \ / \ / \ | S2 | | S3 | | S4 | \___/ \___/ \___/ \ ^ | / \ ARPrpy | | ARPreq(m=5) / \ |_V / \ / \ / ------>x | S5 | x<------- ARPreq(m=10) \___/ ARPreq(m=16) ^ | | | ARPrpy | V ARPreq +----+ | Eb | +----+ Dest. Terminal Figure 6 Path selection and ARP reply Jaihyung Cho Expires July 2005 [Page 11] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 4. Constraint Based Routing The basic mechanism of flooding explained in section 3 achieves lightly loaded path in network. However the path is not a QoS path because no user requirement is considered in intermediate nodes. ARP request message can carry user requirement of bandwidth in TEA field. Last 14 bits of TEA field indicates bandwidth constraint (see figure 4). If user application is LSE capable, source terminal encodes bandwidth requirement in TEA field when the application specified QoS parameter. Intermediate nodes evaluate available resources when the bandwidth field of received ARP request is not null. If the user request for bandwidth cannot be satisfied, the node simply discards the received message. Otherwise, the node performs basic flooding action as described in section 3. The result is that ARP request messages propagate only through links of enough bandwidth. If there are multiple paths satisfying the bandwidth requirement, multiple ARP messages may succeed to reach destination. Among the messages, ARP request of the lowest metric is accepted. As a result, lightly loaded path satisfying the bandwidth requirement is selected for establishment of LSP. Note that in order to achieve QoS routing using flooding, it only added bandwidth evaluation process prior to simple select-and- broadcast action. Compared to other QoS routing proposals, it does not require entire topology map, complex route computation or source routing capability. The simplicity is achieved through diffusion of computation to entire node using flooding. 5. Discussion on Overhead of Flooding One of frequently raised question about flood routing is scalability concerning number of duplicates. Network nodes may repeat flooding when it receive ARP request of lower metric value than previously received one. This may trigger re-flooding of neighboring nodes. As a result, the whole network may produce considerable amount of control traffic. When flooding messages propagate, duplicates of messages race together, and the phenomenon of re-flooding is observed shortly. However network nodes soon converge to a lowest metric value and the flood of messages subsides. Initial simulation result shows that under ideal condition, most network nodes produce duplicates at most twice per session, and the network is stabilized in a few seconds. Therefore, the actual number of flooding frames observed at each link would be negligible considering volume of data traffic. However the worst-case performance in various configurations of network needs to be evaluated in future. Jaihyung Cho Expires July 2005 [Page 12] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 The other concern relates to scale of network. ARP broadcast is network-wide event. As the size of network grows, the number of ARP frames is also increased. In OSPF or IS-IS, large network is sub-divided to small areas and the sub-areas are linked by backbone network. Internal broadcast of sub-area does not propagate to other area unless the information is meant to be global. Similar technique can be used in large flood routing network. A network can be divided according to IP subnet. Border switches of sub-area may filter internal ARP messages using IP address contained in the message. This will reduce global broadcast significantly. Detail of network structuring in large- scale network is out of scope of this document. In conclusion, the amount of signaling traffic in flood routing algorithm is relatively greater than other protocols. However the tradeoff achieved from redundancy of signal is robustness. Note that the flood routing algorithm is so powerful that connection can be successful even when network is severely damaged. Among many duplicates of messages, it only requires at most one message survives and reaches destination via any available path. This, in particular, is desirable feature in some network such as ad-hoc or army network. Considering processing power of modern broadband switches, we believe the overhead of flood routing algorithm is insignificant in LAN environment, and it is worth to trade with benefits expected from new routing technology. 6. Security Considerations It was discussed in section 2. 7. References [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [RFC826] David C. Plummer, "An Ethernet Address Resolution Protocol", RFC826, November 1982 [RFC2814] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks", RFC 2814, May 2000 [RFC2815] M. Seaman, A. Smith, E. Crawley, J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000 [RFC2816] A. Ghanwani, W. Pace, V. Srinivasan, A. Smith, M. Seaman, "A Framework for Integrated Services Jaihyung Cho Expires July 2005 [Page 13] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 Over Shared and Switched IEEE 802 LAN Technologies", RFC 2816, May 2000 [RFC2998] Y. Bernet, et. al, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, Nov. 2000 [LSE] Jaihyung Cho, "Framework for (G)MPLS implementation in Ethernet based Customer Premise Network", draft-jaihyung-ccamp-lseframework-00.txt, Dec. 2004 Jaihyung Cho Expires July 2005 [Page 14] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 Appendix A Example Values of ARP Messages in Figure 1 Following abstract notation shows example of message fields at each stage of ARP procedure described in figure 1. In the notation, 't', 'n', 'b' denote some constant values. 1) Terminal Ea (IP=10.1.1.1) ----> Switch S1 ARP request = { MAC Header = { Dest. Addr = broadcast address; Src. Addr = Ea; Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP request; Sender Ethernet Address = Ea; Sender IPv4 Address = 10.1.1.1; Target Ethernet Address = { Timestamp = null; Metric = null; Bandwidth = b; } Target IPv4 Address = 10.1.1.2; } } 2) Switch S1 ----> Switch S2 ARP request = { MAC Header = { Dest. Addr = broadcast address; Src. Addr = multicast address; Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP request; Sender Ethernet Address = multicast; Sender IPv4 Address = 10.1.1.1; Target Ethernet Address = { Timestamp = t; Metric = 1; Bandwidth = b; } Target IPv4 Address = 10.1.1.2; } } Jaihyung Cho Expires July 2005 [Page 15] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 3) Switch S2 ----> Terminal Eb (IP=10.1.1.2) ARP request = { MAC Header = { Dest. Addr = broadcast address; Src. Addr = multicast address; Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP request; Sender Ethernet Address = multicast; Sender IPv4 Address = 10.1.1.1; Target Ethernet Address = { Timestamp = t; Metric = n; Bandwidth = b; } Target IPv4 Address = 10.1.1.2; } } ARP request procedure ................................................. ARP reply procedure 4) Switch S2 <---- Terminal Eb (IP=10.1.1.2) ARP reply = { MAC Header = { Dest. Addr = multicast address; (% it can be S2 if known) Src. Addr = Eb; Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP reply; Sender Ethernet Address = Eb; Sender IPv4 Address = 10.1.1.2; Target Ethernet Address = multicast; (% or received TEA value) Target IPv4 Address = 10.1.1.1; } } Jaihyung Cho Expires July 2005 [Page 16] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 5) Switch S1 <---- Switch S2 (% allocate Lc, Ld) ARP reply = { MAC Header = { Dest. Addr = multicast address; (% it can be S1 if known) Src. Addr = Lc; (% it can be S2 if known) Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP reply; Sender Ethernet Address = Lc; Sender IPv4 Address = 10.1.1.2; Target Ethernet Address = (% last hop TEA) { Timestamp = t; Metric = n; Bandwidth = b; } Target IPv4 Address = 10.1.1.1; } } 6) Terminal Ea <---- Switch S1 (% allocate La,Lb) ARP reply = { MAC Header = { Dest. Addr = Ea; Src. Addr = La; Length/Type = ARP type (=0x0806); } Message Body = { OP Code = ARP reply; Sender Ethernet Address = La; Sender IPv4 Address = 10.1.1.2; Target Ethernet Address = Ea; Target IPv4 Address = 10.1.1.1; } } Authors' Addresses Jaihyung Cho ETRI 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea Phone: +82 42 860 5514 Email: jaihyung@etri.re.kr Jaihyung Cho Expires July 2005 [Page 17] INTERNET-DRAFT ARP for LSP setup in ECPN February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Jaihyung Cho Expires July 2005 [Page 18]