Enhanced Augmented IP Routing Protocol (EAIRP) in IPv6 Environment

Transcription

1 Enhanced ugmented IP Protocol (EIRP) in IPv6 Environment Loukola M.V. and Skyttä J.O. Department of Electrical and Communications Engineering Helsinki University of Technology, P.O. ox 3, 215 HUT, Finland bstract Data link level forwarding provides simple and fast packet forwarding capability. One primary reason for the simplicity of layer 2 forwarding comes from its short, fixed length labels. node forwarding at network layer must parse a relatively large header, and perform a longest-prefix match to determine a forwarding path. When a node performs layer 2 forwarding it can do direct index lookup into its forwarding table with the short header. It is arguably simpler to build layer 2 forwarding hardware that it is to build layer 3 forwarding hardware because the layer 2 forwarding function is less complex. [2] y bypassing the conventional IP forwarding (the packet assembly/reassembly) process using cell-relaying, we could dramatically reduce both the IP packet processing delay and the queuing delay at the router. [5] Pushing traffic to layer 3 may cause congestion. If data is discarded or lost TCP will backoff. 1. Introduction Data link level forwarding requires a special protocol that establishes the TM cut-through pipelines. This paper introduces Enhanced ugmented IP Protocol (EIRP) which is an IP over TM scheme that is merged to the core of IPv6. In this way the negotiations between the neighboring nodes is reduced to the minimum. Simulations prove that the performance of IRP is superior to other traffic-based IP over TM schemes. [8] The new EIRP includes also control driven approach. Some paths can now be established control-based prior to traffic. Enhanced ugmented IP Protocol is needed for the label allocation for the flows that request layer 2 forwarding. The requests are carried in the Hop-by-Hop Option extension header of the IPv6 [3] packets. In the traffic-based mode as an EIRP capable router receives an IPv6 packet with a layer 2 forwarding request it sends the label to the upstream node and enters the VPI/VCI mapping to the underlying TM switch. Now the upstream node is ready to send IPv6 packets belonging to this flow with a dedicated VPI/VCI value it received from the downstream node. s TM cells with dedicated VPI/VCI value arrives at the downstream node the IPv6 packets are not reassembled, but the cells are forwarded on layer 2. IP packet routing brings along a great delay. That is why IP packet assembly/reassembly should be avoided whenever possible in fast communication. The merging of EIRP to the core of IPv6 gives it the leading position of traffic-based protocols. s the flow length increases the difference between the topology/control based protocols and the traffic-based protocols decreases. s the average flow length being 2 packets the traffic based approach can not forward these flows on data link level. [1] If these flows should be forwarded on layer 2 then control driven is the right one. That is why the control-based label allocation method is added to the IRP [8]. 2. llocation allocation can be made both in traffic-based and control-based. The downstream allocation mode of the IRP [8] is preserved in the EIRP. It is similar to the other designs [9] in the way that the upstream node asks the downstream node to allocate a label for a specific flow. Only in this design no extra request packets are sent. The request for label is carried within every IPv6 packet that belongs to the specified flow. The request for label resides in packet s Hop-by-Hop Option header. Only the label itself needs to be transferred in its own IPv6 packet from the downstream node to the upstream node. The label resides in the Destination Options header of the IPv6 packet with zero length payload. The upstream label allocation mode of IRP is modified to include control-based allocation method. In this mode the upstream node can request the downstream node to allocate labels to different destination IP addresses prior to traffic or after it has forwarded several IP packets on network layer to the same specific destination IP address. The upstream node can make a request to the downstream node to allocate a label to that destination. s the downstream node picks up a label from the free label space is also enters the binding to its label base in order to be ready to forward those cells on layer 2 as the upstream node

2 send them. Once the upstream node has received the label it is ready to start sending packets belonging to the specific flow using the label. The VPI/PCI values are only unique in the physical interface as illustrated in Figure 1. [5] In other words, they are input port specific. It is contingent on TM switches to keep the cells of a PDU contiguous and in sequence. That is why there was a need for a specific solution in case of the former upstream label allocation of IRP [8]. Now in EIRP that need has been erased. Host3 header resides in Destination Options header and contains the label to be used for the specific flow. Once the upstream router has received this packet it can start to send packets belonging to that flow with the specific label (3, Fig. 3). When the 3rd router receives the trigger IP packet (4, Fig 3), it sends the label to its upstream neighbor router (5, Fig. 3). The 2nd Router can now start to send packets belonging to that flow on the dedicated-vc (6, Fig. 4). The label allocation process is illustrated in Figures 2-4. to the upstream node Trigger IP Packet link#3 Host1 Host2 C link#1 C link#2 Node1 link#7 C E link#8 D D Node2 C link#9 D link#4 link#5 Host5 VPI/VCI Translation at Node1 Input Output Source Link VPI/VCI Link VPI/VCI host #8 Host1 #1 #7 C Host1 C #8 E Host1 #7 D Host2 #2 #8 Host2 C #8 D Host2 Node3 Destination Host Host5 Host3 Host6 Host6 Figure 1. TM Cell Multiplexing and Relaying link#6 Host6 Ethernet TM TM Ethernet 1 st Router 2 nd Router Figure 2. Downstream llocation Mode #1 to the upstream node Trigger IP Packet 2.1 Downstream llocation Mode Trigger IP packet starts the cut-through operation (1, Fig. 2). The trigger packet has a Hop-by-Hop Options header in its header chain with the Option Type 1111 (bin). This Option Type is used for all EIRP messages. The trigger packet carries a request for layer 2 forwarding label or layer 3 IPv6 Flow for accelerated layer 3 forwarding. Once the 2 nd router receives such a request it sends the label to its upstream neighbor in a IPv6 packet (2, Fig. 2). This packet has also a Options header with the Option Type 1111 (bin). This Option Ethernet TM TM Ethernet 1 st Router 2 nd Router Figure 3. Downstream llocation Mode #2

3 Cut-Through Explicit Request allocation New entry Ethernet TM Ethernet 1 st TM Router 2 nd Router Figure 4. Downstream llocation Mode #3 2.2 Upstream llocation Mode nother way to achieve cut-through operation is to use upstream label allocation. This means that the upstream node explicitly asks the downstream node to allocate a new label for a new flow (1, Fig. 5). This is not triggered by a request in the Hop-by-Hop Options header, but is either control driven or triggered by the fact that several packets belonging to a new flow have been forwarded to the same destination. fter the downstream node has allocated the label from the free label space it stores the VPI/VCI binding information to its label base (2, Fig. 5) and sends the label to the upstream node in Destination Options header (3, Fig. 6). fter the 1 st router receives the label from the 2 nd router it stores this information to its and is free to send the packets belonging to that flow on the dedicated-vc (4, Fig. 6). The 2 nd router may perform the same explicit label request to the 3 rd router in order to be able to forward the new flow on data link layer (5, Fig. 6). When the 3 rd router received this request is allocated a new label and stores the VPI/VCI binding information to its label base (6, Fig. 6) and send the label to 2 nd router in the Destination Options header (7, Fig. 7). fter the 2 nd router receives the new label from 3 rd router it can update the label base information (8, Fig. 7) and start to forward that flow on layer 2, see Figure 8. Ethernet TM 1 st Router 2 nd TM Ethernet Router Figure 5. Upstream llocation Mode #1 New entry Ethernet TM 1 st Router 2 nd TM Ethernet Router Figure 6. Upstream llocation Mode #2 Explicit Request allocation New entry

4 No label Modify entry Ethernet TM 1 st Router 2 nd TM Ethernet Router Figure 7. Upstream llocation Mode #3 No label Cut-Through Ethernet TM 1 st 2 nd Router TM Ethernet Router In the downstream label allocation mode the request for label is passed in the IPv6 Hop-by-Hop Options header and the label is passed to the upstream node in the IPv6 Destination Options header. oth the Destination Options and the Hopby-Hop Options headers can contain Options in the same format [3]. s are expired with to use of an explicit label removal message. When there has not been any packet carrying that specific label for 18 seconds the upstream node sends the label removal message to the downstream node. fter that the downstream node deletes the binding from its. 4. llocation Methods The EIRP downstream mode exchanges layer 2 labels based on traffic like IP switching and control-based like Multi Protocol Switching (MPLS) [2]. This reduces the overhead of exchanging labels between all peers in a routing domain and reduces the size of the label binding information bases in routers. Topology-based methods have the ability of forwarding all the packets on layer 2 including the first packets of each flow, while in traffic-based methods the first packet has to be reassembled in all the routers along the packets delivery path. Control-based methods have the ability of selecting the paths that will be preconfigured to VCs. This approach has the scaling advantage over the topology-based protocols that will establish all possible paths to VCs prior to traffic. Some of these paths may never be used. The allocation of VCs to all possible paths introduces a scaling problem in large networks. EIRP upstream mode utilizes the control-based method. The nature of the bindings in the is soft-state as the connections are established due to the requests. ut on the other hand there is no refreshment procedure or keep-alive messages between the neighboring EIRs. Figure 8. Upstream llocation Mode #4 3. Distribution distribution occurs between TM switches which have been augmented with standard IP routing support. The IP Routers must be able to recognize the IPv6 Option type (1111 bin) used in this design. Such IP Routers are referred as Enhanced ugmented IP Routers (EIRs). The word augmented here refers to the EIRs ability to recognize the needed IPv6 Option type.

5 5. EIRP Messages 5.1 General The EIRs need to exchange information with each other. That is why a simple Enhanced ugmented IP Router Protocol (EIRP) is needed. The messages are transferred within the IPv6 packet s Hop-by-Hop Options header or the Destination Options header. 5.2 Message Types Three kind of message types are defined: 1) request for label message, 2) label transfer message, 3) label removal message, and 4) explicit label request message Request Message This message must be within all the IPv6 packets belonging to the same flow that want special EIRP treatment. The first packet triggers the downstream label allocation procedure if there has not been control driven allocation prior to this. 1 shows the format of the Hop-by-Hop Options header. 1 st Next Header 2 nd Hdr Ext Len = th ction = 1 6 th [23..16] 7 th [15..8] 8 th [7..] 9 th - 24 th Source ddress of the IP packet that triggered downstream node label allocation 25 th - 4 th Destination ddress of the IP packet that triggered downstream node label allocation 41 th - 43 th Flow of the IP packet that triggered downstream 44 th Reserved node label a 45 th Reserved 46 th Reserved 47 th Reserved 48 th Reserved 2. Format of The Transfer Message This message is within an IP packet with zero length payload. s the upstream EIR receives this message, it is ready to use the VC for the specified flow Removal Message If the upstream node wants has not received any packets belonging to specific flow that has a entry it must send a label removal message to downstream node in order to delete the binding in its. The format of the Destination Options header for the label removal message is shown in 3. 1 st Next Header 2 nd Hdr Ext Len = 5 th ction = 6 th Reserved = 1 7 th Reserved = 1 8 th Reserved = 1 st Next Header 2 nd Hdr Ext Len = 1 5 th ction = 11 6 th [23..16] 7 th [15..8] 8 th [7..] 1. Format of The Request Message fter a downstream EIR receives this message it allocates a 24-bit label to be used for the flow, and enters that label to its. fter the label is entered to, the downstream EIR sends a label transfer message to the upstream EIR Transfer Message This message is a response to the label request message or to the explicit label request message. 2 shows the format of the Destination Options header. 3. Format of The Removal Message This message is sent on default VC. fter this the downstream node deletes the binding from its and can make use of the same label immediately after the deletion Explicit Request Message In the control driven label allocation there is a need for a explicit label request. This request has not been triggered by a label request by the user. 4 shows the format of the Destination Options header.

6 1 st Next Header 2 nd Hdr Ext Len = 11 5 th ction = 6 th Reserved = 1 7 th Reserved = 25 th - 4 th Destination IP ddress th Reserved = Simulation results of the first simulation can be seen in Fig. 1. EIRP downstream has superior performance over the other IP switching protocols due to the fact that no traffic classification is needed because the EIRP downstream signaling is triggered on a request in the IP hop-by-hop options extension header. EIRP downstream features also minimal signaling messages between the neighboring nodes as only the label to be used is transferred. 4. Format of The Explicit Request Message Once the flow is selected for upstream allocation method and a dedicated-vc is already allocated the EIR is ready to update the entry information and start forwarding packets belonging to that flow on the dedicated-vc. 6. Simulations nd Results EIRP as well as the other IP switching protocols were simulated on a fixed platform, see Fig. 9. The network topology, applied performance values, traffic profiles, and the presumptions are identical to earlier simulations [8] performed with IRP. max forwarding speed / Mbps flow length / packets 4 Topology/Controlbased protocols (EIRP Upstream) EIRP Downstream Updated IFMP CSR - traffic-based Normal Forwarding With CFH TM 625 Mbps Host L Router Link11 Link6 Link1 Host1 Router1 Link12 Router5 Link5 Host5 Link13 Link7 Link1 Figure 9. The Simulation Platform Link2 Host2 Router2 Link14 Router6 Link15 Link16 Link17 Router4 Link4 Link8 Router3 Link9 Host3 Figure 1. The Dependence on Flow Length in Forwarding Speed The second simulation was made in order to find out how the mixture of EIRP upstream and downstream traffic would effect the performance of the simulation network. Figure 11 illustrates the dependence on the amount of EIRP upstream traffic in maximum forwarding speed of the middle router/switch. The rest of the traffic is EIRP downstream traffic. The flow length is fixed to 2, which is the average flow length in the Internet at the moment [1]. s Fig. 1 shows trafficbased methods do not accelerate the maximum forwarding speed until the flow length is increased to some 5 packets. When the flow lengths are small the dependency is almost linear as Fig. 11 clearly indicates. Fig. 11 also shows the percentage of EIRP upstream traffic after it has gone through the middle router/switch. Packets belonging to flows that are established by EIRP upstream allocation can be directly forwarded on the middle router. That is why the percentage of upstream traffic increases so rapidly.

7 Maximum Forwarding Speed (MFS) (Mbps) MFS 5 Percentage of EIRP Upstream Traffic efore The Middle Router/Switch 6 fter Figure 11. The Dependence on the amount of EIRP Upstream Traffic in Forwarding Speed 7. Conclusions Percentage of EIRP Upstream traffic fter The Middle Router/Switch (fter) Topology-based protocols like Tag Switching [4], ggregate Route-ased IP Switching (RIS) [6], Switching IP Through TM (SIT) [7], Cell Switch Router [5], and EIRP in control driven mode can exploit full TM forwarding speed because the TM switches are preconfigured when the IP packets arrive. Traffic-based protocols differ from each other in the way they establish layer 2 forwarding. Those differences effect the maximum forwarding speeds of the appropriate protocols. s the average flow length increases the performances of traffic-based approach compared to topology-based protocols increases as well. Merging IP switching protocol messages to the core of IPv6 decreases the number of packets that have to be sent between the neighboring nodes. This in its turn increases the overall forwarding performance. The mixture of traffic-based forwarding and control driven cut-through establishment must be carefully planned and simulated in order to optimize the network and to get the maximum performance with a limited number of VCs. When one VC is allocated to each flow there is no need to aggregate traffic from different sources to the same VC. The topology-based methods establish VCs for all possible edge node pairs prior to traffic. In large network like Internet, that is not possible due to the limitation of the TM chips. The mixture of control and traffic driven allocation gives the network a new tool to network management. Some VCs will be preallocated for the most popular paths in order to avoid traffic-based signaling in the future. s the majority of traffic get the best-effort layer 3 forwarding EIRP enables a good and very controlled way of cutthrough establishments. References 1] be G., Technical Foundations of Residential roadband, Macmillan Publishing US, 1997 [2] Callon R., et. al., " Framework for Multiprotocol Switching", Network Working Group, Internet Draft <draft-ietf-mpls-framework-.txt>, May 1997 [3] Deering, S., and Hinden, R., Internet Protocol, Version 6, Specification, RFC 1883, Xerox PRC, Ipsilon Networks Inc., December 1995 [4] Doolan, P., et. al., Tag Distribution Protocol, work in progress, Internet Draft <draft-doolan-tdp-spec-.txt>, Cisco Systems Inc., September 1996 [5] Esaki H., et. al., "White Paper on CSR (Cell Switch Router) Provided by TOSHI Corporation", TOSHI Corporation, pril 1997 [6] Feldman, N., Viswanathan,., RIS Specification, Internet Draft <draft-feldman-aris-spec-.txt>, IM Corporation, March 1997 [7] Heinänen J., Updated SIT Proposal, url valid: ugust 27,1998, Telecom Finland, November 1996 [8] Loukola M.V., Skyttä J.O., IPv6 over TM flow-handling, Computer Communications (21)13 (1998) pp [9] Newman, P., et. al., Ipsilon Flow Management Protocol Specification for IPv4 Version 1., Ipsilon Networks Inc., RFC 1953, May 1996