Dynamic Classification in Silicon-Based Forwarding ... - CiteSeerX

Dynamic Classification in Silicon-Based Forwarding Engine Environments R. Jaeger1,2, R. Duncan2, F. Travostino2, T. Lavian2, J. Hollingsworth1 1 University of Maryland, College Park, MD 20742 2 Nortel Networks, 4401 Great America Parkway, Santa Clara, CA 9505 {rfj,hollings}@cs.umd.edu {rduncan, travos, tlavian}@nortelnetworks.com Abstract--Current network devices enable connectivity between end systems with support for routing with a defined set of protocol software bundled with the hardware. These devices do not support user customization or the introduction of new software applications. Programmable network devices allow for the dynamic downloading of customized programs into network devices allowing for the introduction of new protocols and network services. The Oplet Runtime Environment (ORE) is a programmable network architecture built on a Gigabit Ethernet L3 Routing Switch to support downloadable services. Complementing the ORE, we introduce the JFWD API, a uniform, platform-independent portal through which application programmers control the forwarding engines of heterogeneous network nodes (e.g., switches and routers). Using the JFWD API, an ORE service has been implemented to classify and dynamically adjust packet handling on silicon-based network devices. Index terms-- Programmable Networks, Active Networks, ORE, JFWD, Distributed Applications, Networking Protocols, Differentiated Services

I. INTRODUCTION Programmable networks enable the introduction of user computing to network devices to provide new and improved services and distributed application functionality. Traditional networks deliver packets between endpoints using protocol software that is bundled with the hardware. Network devices do not support user customization or introduction of new software applications nor do they facilitate introducing new protocols quickly. This paper details a policy-based packet classification technique that is downloaded to a programmable network device to dynamically adjust the DS-byte in the IP header of real-time flows on a silicon-based forwarding engine. The technique is implemented using the Oplet Runtime Environment (ORE), a network services platform which supports dynamically loaded Java services. Crucial to the classification engine is the JFWD network API which provides control of the forwarding plane operations. We demonstrate that we can support Java-based services and implement packet sampling, processing, and forward policy adjustment on a commercial-grade, silicon-based, Gigabit L3 Routing Switch. The remainder of this paper is organized as follows. Section 2 introduces the Oplet Runtime Environment (ORE).

Presented in IEEE LAN/MAN Australia 1999

Section 3 introduces the JFWD networking API. Section 4 discusses implementation of a technique for doing besteffort packet classification for Quality of Service improvements based on packet sampling and policy-based DS-byte (formerly ToS) modifications. The conclusion is presented in Section 5. II. THE OPLET RUNTIME ENVIRONMENT (ORE) The Oplet Runtime Environment (ORE) described in this paper supports dynamically injecting customized software services into network devices. The implemented architecture is composed of an embedded Java Virtual Machine (JVM) and the ORE. The ORE component provides the substrate on the network device to support the secure downloading, installation, and safe execution of services. Since the ORE and its services are constrained to running in the JVM, system stability of the core network device operations is not affected. Customized ORE services, which run locally on network devices, include monitoring, routing, diagnostic, or other user specified functions. ORE services can monitor and change specific Management Information Base (MIB) variables locally on the device through the Java MIB API [3]. Direct access to MIB variables on network nodes greatly improves scalability and reduces network traffic compared with using SNMP agents to perform remote "get" and "set" operations [3]. The ORE architecture attempts to mediate the shared resources (memory, CPU, persistent storage, and bandwidth) between mutually suspicious services and to provide for inter-service communication including the sharing of objects and calls into other services. The ORE architecture consists of the ORE environment, oplets, and services. Oplets are self-contained downloadable units that encapsulate one or more services, service attributes, authentication information, and resource requirements. Oplets can provide services to other oplets and can depend on other services. The ORE provides machinery to download oplets, manages the oplet lifecycle, maintains a registry of active services, and tracks dependencies between oplets and services. III. JAVA FORWARDING API

We have implemented a network API on a commercialgrade, ASIC-based, L3 Routing Switch that allows ORE services to request alternative packet handling from the hardware forwarding plane. The JFWD API specifies interfaces for Java applications to control a generic, platform-neutral forwarding plane. The JFWD API consists of a collection of Java classes specifications. The implementations of these classes is not considered part of the JFWD API technology, because it is code that, unlike the API, is highly platform-specific and thus lend itselfs to other distribution strategies. JFWD is the first Java API package to explicitly address the needs of contemporary forwarding planes of network nodes which are increasingly implemented in silicon, must support multiple protocols, and must realize Quality-of-Service (QoS) low-level functionality. To drive an ever-growing number of options, more diversified control data will have to be fed into control planes. The JFWD implementation across multiple hardware platforms brings a) the abstraction of a platform-neutral forwarding engine, b) a framework within which new protocols and control data can be described, and c) a new breed of shrink-wrapped Java programs for controlling network nodes. [2]. IV. JFWD APPLICATION ORE services can use the JFWD API to instruct the forwarding engine to divert packets from the data plane to the control plane. To support a new breed of routerbased programs that do not delay packet forwarding, we use the JFWD API to instruct the forwarding engine to send packets to both the data plane output queue and also to the control plane. This feature, called CarbonCopy, does not divert packets to the control plane; it performs wire-speed forwarding while copying the packets to the control planes. By allowing ORE services to modify the packet handling in the ASIC forwarding engine, new types of applications are possible that do not require core router functionality to be altered. In [5], the authors present a control-on-demand architecture in which flow control is performed on a best effort basis. An IPv4 flow is determined by five fields in the IPv4 header: the IP source and destination address, the source and destination port numbers, and the protocol. Packets belonging to a flow are copied to the control plane for processing while simultaneously forwarding the packet. This is our approach as well. It deviates from the store-execute-forward paradigm of Active Networks. We implemented an ORE service, called the DiffServ Classification service (DSC), to classify flows and modify packet headers based on the policy set for a particular protocol contained in the IP header. A policy

Presented in IEEE LAN/MAN Australia 1999

determines the action to be taken for a particular flow or class of flows. A policy filter executes the actions specified in the policy. Our implementation samples packets from the data plane using the CarbonCopy feature of the JFWD API. To accomplish this sampling, the DSC service sets the CarbonCopy filter on all ports, which instructs the forwarding engine to copy some number of packets from each port into the control plane. Next, the DSC service retrieves the delivered packets. Each packet is parsed to determine if a policy filter has been set for this flow. If no filter is set for the flow but a policy exists for this protocol, a policy filter will be created for this flow and will be applied to ports in the forwarding processor(s). The policy filter created for a particular flow is based on the IP header fields in the packet that determine a flow. The value of the DS-byte field in the IPv4 header is set for all packets in the flow. The new value of the DS-byte value is determined by the policy for that protocol type. In our prototype, our policy is to set the DS-byte field for all packets where the protocol is RTP. For each RTP packet sampled, the service checks for an existing filter. If no filter exists for this flow, the RTP policy of setting the DS-byte is executed by setting a filter in the forwarding engine. This modifies the forwarding engine behavior to set the DS-byte field for all packets of that flow. It is a best effort classification, since the sampling of packets is random and may not acquire the packets from a particular flow in a timely manner. V. CONCLUSION We implemented a stable programmable networks platform capable of running dynamically loaded services on a commercial-grade Gigabit L3 Routing Switch. The ORE supports the creation of services in Java that are extensible, portable, and easily distributed over the network. It provides a platform for safely running these services without disturbing the existing core functionality of the router. Through the JFWD API, the packet capture, processing, and modification capabilities are realized at the programmable node. Because of the CarbonCopy and filter mapping features provided in the JFWD API, we were able to create an ORE service to perform dynamic DiffServ Classification and DS-byte adjustment in an effort to improve the performance of specific types of network flows. VI. REFERENCES
                  ! "# $ % &" ' (  " )*  + # , - . / 0 1 2 - 3 4 5 6 78 5 9 5:6 ; ? 7 @ ACB D E D F G H H IJ FLK*FM N N OH E D G J P H QSR T U V W R XLY R Z [ \ ]:^ QSQSQ`_ a XbW[ U c XdW RCeV W f V g XXU Rf hi jk l i k m npo qrs m i t u v w xLySz {| } ~ v  w €  ‚*ƒƒ  w „ € v w … {~ † ‡ˆ‰ Špz ‚S‹ Œ  Ž  ’‘ “ ” • “  – — ‘ • ˜ ™Lš › œ Œ  Ž œ

 ž Ÿ S¡ ¢ £ ¤ ¥ ¤ ¦ §  S¡ ¨© ª« £ ª§ ¬¡ ­ ¦ £ ® ¯° ± ² ª¯ § ­*¡ ³£ ® ² £ ª §S¢ ¡ ´µ ¶ ¶ · ¸¹ º »:µ¼ ½ ¾ ¿À Á*¸CÁ: ½ · à ÄSÅLÄ ½ »:µ¼ Æ ºpÇ Ä ¼ à · Â Ä ºÁ:¼  ¾· ½ Ä Â ½ È ¼ Ä É µ ¼Ê µ È ½ Ä ¼ º»*· ½ ¾LÇ · ¶ ·  µ ¸ Ë ÌpÍ º Ä ÎÐϵ ¼ »*Í ¼ Î · ¸ ¹:ÑS¸¹ · ¸Ä º À ¿ Ò Ó ÔÕCÖ × × Ø ÙÚ× ÛÜCÝØ Þ ß:à á âLã ä ä`åæ à á âCç ä ä ä è é ê ëìSí îï ð ñ ï ò ó ôSí õ ï ö ÷ ö ø ó õ í  ù ú û û ñ ò ÷ ü ý:ú ø þ ÿó
ö òø ú ÷ ø ï   ï  û ö  ø ÿ ñ þ ö þ

ø ö  ú ø õ ï ð ï ö ò ï  û öLö þ ý:ú ø Lö ð ñ ö ü ó  þ ï ò úø  ùú þ òþ ö ø ú ò òö þ ü ó  ÷ ü þ    í    
 "! # # ! $ "! % & ' '(' #)! *  +,- . / 0 1  2 342 / 5 6
7 8 0 ,
9 : ,;=6
,
9 2 ? / 0 6 ,)@ A 2 . B
,"0 . : C D>2 E"6"7 /)FG A H < H I J K L M N
O>P Q Q R S R(PTO>P UWV
X Y Z ["S N \ R P"] S Z ^_ [` Y Z Y X Y R(PT"a>R b c
[P Q
P S d Ne I I J f g h i)j4k  l m n o p qWr s t t u
v
w
x k yz"n r r n { " z n | m } ~  €>
‚
ƒ „ 
…
 ‚†4~ ‡Wˆ ‚‰
Š ‹(‚ ~ Œ Œ  Ž  ~ ‚
ƒ)ˆ 
"„ 
ˆ Ž W  ƒ W„  ‘ ƒ ~ „)"  „ 
’ „ ˆ ‡W‡ˆ “" …  ƒ ”  ‹(„  …"• – – – — ˜ ™ š› œ ( ›  žŸ  
Ÿ ¡  "¢£ œ ¢ ¡(£ Ÿ ¤ ¥ ¡ œ ¦>§ ¨(¡ © ¢
ª¬«)© § ­ © ¡  ž žW¡
® ¤ ¯W ° ¨ §"© ± ª œ ² ³W² ´"² µ¬¶ ² ·(··¸² ³
¹ º » ¼¾½"¿ À
Á ½ Ã4½ ³WÄWÅ Á ¹ ¿ Å " Æ Ç ¹ È ÉÊ Ë Á ¹ È Í Ì ÁÎ Ï Ã"È ¿ Ð ¹ Å ½
³Á)Ð ³"É=ÑÒÐ ³"Ð Ó È Ì4È ³"¹ Ô"Õ Ö Ö × »

Presented in IEEE LAN/MAN Australia 1999

________________________________________________ ÜÝ Þßàâá ãåäæ ß(ç)ç)á è á ã)ß(é á êÞ ë ìîíîïë ð ë ñ¬òì ó
ô í(õö÷ ø)ù=ú ûýü ú þÿ 

=ÿ 

________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________

Rob Jaeger1,2 [email protected] [email protected]

Tal Lavian2 [email protected]

________________________________________________ ________________________________________________

1

Technology Center, Enterprise Solutions, Nortel Networks 2 Department of Computer Science, University of Maryland

________________________________________________ Ø ÙÚ ÙØ Ø

     

Û

________________________________________________ ________________________________________________

          ! ! " # $ % & '( ) * + , - - . / . 0 , 1 . 2 34. 35 . + . 0 2 3 6 7 8 9 : ;< = > ?@8 > ; A B C D E F G H I G JLK I M N O P4Q R S F T4O M R S S N H N O R U N I VR V TJI T N H N O R U N I V4I H W X Y Z [ \] ^ _ ` a b c d e4c f g a h d i b a jd k h l i m ii ` ` n c b i g c k f jg k4b k f g h k n i o p q p r s t u v w x y z { r |} q p ~ y r x w z { r x r € s q ov w x q p  ‚ ƒ „ … † ‡Lˆ ‰ ƒ „ Š‹ Œˆ  Žƒ †  „ ˆ ‹ ƒ 4  ‘ ‡ ’ “ ‹ Œ ‡ ‘” ƒ ‡ ” Ž@ ’ • ˆ ‡ “ ‹Œ ‡ ‘ – — ˜ ™ š › œ ž ™ ˜ › Ÿ    ˜ ¡ ¢  ˜ š › £ £ ™ ¤4¤¥ Ÿ › £ ¦   › ™ Ÿ› Ÿ £ § ¥ œ › Ÿ ¨4  ©  ª « ¬ ­ ® ¯ °4± ² ± ³ ´ µ ¶ · ª¬ ¯ ¸4¶ ¬ ¹ ¹ ª® ¯ · ±4± · « µ ­ ª µ ­ º ® ¶ µ ª

________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________



________________________________________________ Open Device Architecture

________________________________________________ ________________________________________________

ORE Service C/C++ API

Java MIB API

JNI Device Drivers

JFWD API

Device Code

Java API

________________________________________________ ________________________________________________

Oplet Runtime Env

________________________________________________

JVM

________________________________________________

Operating System

Device HW

________________________________________________

» ¼½ ¼» » ¾ ÀÂÁ ÁÃ4ÄÆÅÇ È ÉÊÄÌËÍÎ É Ï Ð Ñ ÒÓ Ô Õ Ö × Ø × Ù Ó Ô Ú Û Õ Ö Ü Ý@Þ Ó ß à × Ô áâ ã × à Ù ä å æ ç èé æ ê ë ì í ç î ï é í ð ñ ìè ï ò ð ó ô ï ñ ì ï í õ ö ÷ ø ÷ ù ú û ÷ ü ý ú þ@ÿ ú ø
ú  
  ú
   ú

________________________________________________ ________________________________________________

                     !    "     #    $ %  & '  ( ) * + , - . / 0 - 0 1 2 3 2 4 5 1 5 6 7 0 2 8 5 9 : ; 5 9 8 3 9 < 4 1 = > ? ,

________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________

@ >L /M N/ 5O O 6 P Q 2 P A R 4N B S P 0 T 1 U3 PC U / 0 V B P M 4P R- T . U / W0 X - N 0 O Y1 Z\ 2 3 2[ 4 T 5 ] 1 ^ 5 N 6 ] Z D P UE _ F G HJI K

¿

________________________________________________

Presented in IEEE LAN/MAN Australia 1999

________________________________________________

________________________________________________

dfehgji kmlon prq sutwvwx y z {j|~}rvroz € ‚v‚{j|wvry

________________________________________________ Oplet 1

Service A

________________________________________________

Oplet 2

Service B

________________________________________________

Service C

________________________________________________ ORE

________________________________________________ JVM

________________________________________________ ________________________________________________ ` ab a` `

c

„†…o‡rˆ‚‰‹Š ŒŽw‚‡r Š ‘‚’w“ ˆJ” Š ‚‡jo–• ‚“ —˜ˆo“ ™‚Š ‡r‘›šu’wœ rž

________________________________________________ ________________________________________________

Dynamic Policy

________________________________________________

CPU

________________________________________________

Forwarding Rules

________________________________________________

Forwarding Processor

Forwarding Processor

Forwarding Processor

Forwarding Processor

________________________________________________ ________________________________________________ SW

________________________________________________

HW

ƒ  \¡¢¤£¦¥w§w¨ ©rªw«o¥‚ª‚¬J­j¥‚§o¬r§w©o® ¯ ® ° ­

________________________________________________ ________________________________________________

CPU

________________________________________________ ________________________________________________

Forwarding Processor

Forwarding Processor

Forwarding Processor

________________________________________________

Forwarding Processor

________________________________________________ ________________________________________________ ________________________________________________ Ÿ

________________________________________________

Best-Effort Classification Policy

________________________________________________

Filters

________________________________________________

filter

Pac

ket

DSC Service

________________________________________________

Priority Packet

Forwarding Processor

________________________________________________

Forwarding Processor

Packet

________________________________________________ ________________________________________________ ± ²³ ²± ±

Presented in IEEE LAN/MAN Australia 1999

³

________________________________________________