APLS: Active Protocol Label Switching

APLS: Active Protocol Label Switching William Lau and Sanjay Jha School of Computer Science and Engineering The University of NSW, Kensington Sydney 2052 Australia wlau,[email protected]

Abstract— The current trend of increasing accessibility and reachability of the Internet has resulted in many new services at the application layer. The potential growth of services on the Internet is only restricted by the network technologies that realize the Internet. In particular, Layer 3 technologies are conventionally inflexible and do not adapt well to rapid changes in the Internet environment. Service-oriented networks should be more user-focused, which includes providing mechanisms that show value to the network providers, service providers, and clients. The next generation networking technologies must not only excel in performance, but also in flexibility, control, and scalability. This paper introduces a new network architecture called Active Protocol Label Switching (APLS), which establishes a foundation offering the same level of performance and scalability as current label-switching architectures but with the flexibility and control that existing label-switching architectures lack. All existing label-switching architectures position the label as a shim layer between layers 2 and 3. The major reason behind this is to make the architecture network protocol independent. However, in designing APLS we investigated the merit of a new concept: Label Switching Over IP. Several other new concepts are introduced: Virtual Label Space, Micro-Instruction Architecture, and Micro-Policy-based Forwarding. We will also focus on how APLS can be combined with Active Programmable Networks to offer services at an unprecedented level. Index Terms— NGI Architecture, Label Switching, Active Networks

I. I NTRODUCTION The current trend of increasing accessibility and reachability of the Internet has attracted a huge volume of services that range from financial transactions to entertainment. The potential growth of services on the Internet is only restricted by the network technologies that realize the Internet. In particular, the Layer 3 (L3) technologies are conventionally inflexible and do not adapt well to rapid changes in the Internet environment. Traditionally, L3 technologies are focused on performance (bandwidth/delay/jitter) to cater for network providers’ needs. However, the introduction of service provisioning on the Internet has generated a new type of stakeholder, the service provider. Service providers offer value-added services to their clients over the Internet. Examples of modern Internet service providers are those who offer online service, online-gaming, and IP-telephony. The current philosophy is to fit the services around the best-effort Internet. The hypothesis behind this paper is to analyze the opposite approach, i.e., how should the Internet evolve into a service-provisioning internetwork? Research is partially sponsored by CSIRO Centie Project (www.centie.org)

We envision that the L3 network will play a larger role in service provisioning and changes will focus on making the IP model more service-oriented. Service-oriented networks should be more user-centric, which includes providing mechanisms that show value to the network providers, service providers, and the clients. The next generation networking technologies must not only excel in performance, but also in flexibility, control, and scalability. Flexibility allows the network to rapidly adapt to the latest trends in services that will have different characteristics – the future holds the unexpected. Control is in respect to network resources for both differential service and traffic engineering. However, control must incorporate two perspectives. The first is for the network providers who are the ultimate controllers of their networks. Network providers want more fine-grain control that is easier to operate and maintain. The second is for the service providers who will benefit from some form of delegated control of the network. Service providers must respond faster to their clients or potential clients. They also have traffic knowledge of their services to improve utilization of the network while satisfying their customers’ needs. This paper introduces a new network architecture called Active Protocol Label Switching (APLS), which establishes a foundation offering the same level of performance and scalability as current label-switching architectures, but with the flexibility and control that existing label-switching architectures lack. This foundation will form the basis for incorporating complementary technologies, such as QoS and Active Programmable Network (APN) Architectures, for further flexibility and control. In particular, we will focus on how APLS can be combined with APN to offer services at an unprecedented level. The rest of this paper starts with related work in Section II and then the APLS network architecture is introduced in Section III. This is followed by a brief discussion of how APLS can be controlled in Section IV, and a presentation in Section V of APN over APLS and the new network model it supports. We then investigate an example of service provisioning using APN over APLS in Section VI. Section VII finally concludes our proposal for a service-oriented nextgeneration network. II. R ELATED W ORK The existing IP architecture provides performance and scalability but lacks the control and flexibility desired in a

service-oriented network. Proposed QoS Architectures like DiffServ [1] and IntServ [2] offer a high degree of network resource control. However, they lack flexibility and do not delegate control to service providers. QoS Architectures alone are too static and the only flexibility offered is the flexibility to choose between a static set of service classes or the different parameters to form the resource specification. Therefore, QoS Architectures should be combined with other mechanisms to realize a higher degree of flexibility. ATM [3] integrates label-switching performance with QoS control to offer a platform that performs well for a wide variety of traffic characteristics. However, ATM is designed with control in mind only and lacks flexible mechanisms. The scalability of ATM virtual connections to support the next generation Internet is also questionable [4]. ATM does not delegate control to service providers. Although MPLS [5] overcomes the scalability issues in ATM, it suffers from the same drawbacks as ATM in terms of flexibility. Active Programmable Networks [6] (APN) introduce a new type of service model, which promotes a higher degree of flexibility and control. APN proposes opening up the network to allow special computations to be executed. This computation can manipulate data contents or change the forwarding behavior. However, performance and scalability issues must still be addressed for APN technologies. Tempest [7] attempts to modify ATM to become more flexible and give a higher degree of control. The objective of Tempest is to modify the control plane of the ATM architecture and it introduces a new logical entity called switchlets, small virtual switches that share the same physical resources in the ATM switch. Different control architectures or controllers can then coexist with each controller isolated inside a switchlet. The standard ATM PNNI signaling protocol is one example of such a controller. It is possible for network providers to deploy customised control protocols. If service providers are allocated their own switchlets across the ATM network, they are given delegated control of routing and forwarding. The problem with the Tempest approach is that it inherits many limitations from the ATM forwarding plane e.g., scalability issues for VCs, and the complexity of operating and maintaining VCs. The ATM forwarding plane is also not flexible and thus limits what Tempest can potentially do. III. ACTIVE P ROTOCOL L ABEL S WITCHING (APLS) MPLS offers only the forwarding architecture and separates QoS control from the design. Hence MPLS delivers relatively simple but effective label-switching technology. APLS inherits the general label-switching concepts from MPLS for performance and scalability while contributing novel mechanisms that promote flexibility and control. APLS is a forwarding architecture designed with service provisioning in mind. The new concepts introduced by APLS are: label switching over IP, virtual label space, micro-instruction architecture, and micro-policy-based forwarding. We provide a brief overview of the key features of the APLS architecture. Lau et al. [8] gives a more detailed discussion of APLS and a prototype implementation based on Linux.

MPLS Protocol Stack

Fig. 1.

APLS Protocol Stack

Transport Layer

Transport Layer

Network Layer MPLS

APLS Network Layer (IP)

Link Layer

Link Layer

Physical Layer

Physical Layer

MPLS and APLS protocol stack

A. Label Switching Over IP Breaking out from the conventional label-switching approach, we investigated the advantages and disadvantages of positioning of the label in the network stack. All existing labelswitching architectures [9], [10], like MPLS, position the label as a shim layer between L2 and L3. The main reason behind this is to make the architecture independent of the network protocol. Independence allows multiple network protocols and traffic to be supported in one network infrastructure. However, these approaches are intended as short–medium term solutions to the current network environment where much legacy network traffic still exists and must be supported. Looking more into the medium–long term, IP is expected [11] to dominate network traffic in the next few years. Thus the question: Why not design a label-switching Architecture specifically for IP? This new perspective led to a new concept of Label Switching Over IP (LSOIP), i.e., positioning the shim layer between L3 and L4. Fig. 1 shows the difference in positioning between MPLS and APLS. Firstly, let us look at the advantages of LSOIP. 1) LSOIP can take advantage of IP header fields, so does not need to include redundant overhead as seen in IP over ATM/MPLS. e.g., TTL, DSCP, checksum fields can be exploited. 2) LSOIP architectures allow the coexistence of IP traffic along with label-switched traffic in the same network infrastructure. The attractiveness of coexistence is paramount in terms of incremental deployment and traffic migration from IP to LSOIP [8]. By achieving coexistence, the network becomes more robust in fault scenarios as well. For example, if a faulty LSP is being re-established, traffic can continue to flow using the robust IP forwarding system. MPLS supports coexistence through the use of a dummy label to deliver packets to the IP routing module. This requires special support and configuration for MPLS routers to detect whether its adjacent routers are MPLS or IP routers, and also an additional overhead for the label. 3) IP has become the universal network interface and its dominant acceptance calls for a long-term model of Internet protocols. The major disadvantage of LSOIP is its dedication to direct IP support only. However, we argue that this disadvantage would be only for the short term for the following reasons.

APLS Label Specification 64 bits SID (24 bits)

AID (16 bits)

FID (16 bits)

S flag (1 bit) EXP (7 bits)

Fig. 2.

The APLS label

1) IP is dominating the network arena in the near future thus by Amdahl’s Law: Optimize the Common Case, LSOIP makes sense. 2) Legacy network traffic can run over LSOIP with the additional overhead of a dummy IP header, but as these networks are being phased out and the percentage of their traffic is becoming less significant, this overhead is expected to be temporary and minimal. Therefore, LSOIP has the attractions to play a significant role in the next generation Internet. B. Virtual Label Space MPLS’s label consists of the label space and other auxiliary fields. The label space is the key to the forwarding tables in the Label Switch Routers (LSR). The label space used by MPLS has no implicit structure and thus is considered as a flat label space. In APLS, we envision a network that delegates forwarding control to the service providers. This leads to the concept of the Virtual Label Space (VLS). VLS hierarchically structures the label space into three components as shown in Fig. 2. The first eight bits of the APLS label are the auxiliary fields consisting of one bit for the bottom of stack flag and seven bits for experimental use. The 56 bits make up the VLS, which includes the Service ID (SID), Aggregate ID (AID), and Flow ID (FID). Service providers requiring forwarding control will lease a VLS from the network provider. Each of these service providers is allocated a unique SID where the Effective Virtual Space (EVS) that consists of both AID and FID, is under the control of the service provider. In APLS, the interpretation of the AID is optional. AID allows APLS to support an aggregation concept the same as that of ATM’s VPI [3]. If an implementation does not support AID then the FID field will consist of 32 bits. The FID field identifies the flow and together with SID and AID, identifies a LSP. The SID field is fully under the control of the network provider and is global in the network domain, i.e., the SID field is not switched by the LSRs as AID and FID possibly would be. This forms a level of protection between VLSs and also simplifies the maintenance of label space partitioning and allocation. Although APLS’s label is 32 bits larger than MPLS, APLS offers higher scalability and promotes control at the service provider level. Merwe et al. [7] attempted to delegate control of the label space through the control plane only, without the support of the forwarding plane. This required virtual partitioning

of the label space through some control mechanism. The advantage of this method is that it hides the partitioning from the forwarding plane. However, the disadvantage is that it requires a complex partition management system. Partitions must be made on a per-LSR basis since label space is local to each LSRs. Once this is done, each LSR needs to know what partition is allocated to its adjacent neighbours, because we must protect SPs from each other. Other issues include deleting partitions, the ability to freeze whole partitions and resource management. SID simplifies partition management because the partitioning is explicit in the label space and is global across the domain. Creating a partition only requires allocating a SID and setting up resources in LSRs for this SID. Deleting and freezing partitions are simple, as the forwarding plane implicitly supports SID. Hierarchical label stacking is also cheaper, because only the label-switched component (EVS) is stacked. Potential performance implications can also be seen from the simplification of partitioning and also from the potential design of data structures inside the switch that are customized for the partitioning characteristics, e.g., rather than using one data structure instance that stores every partition, we can use one hash table for SID and one instance of the data structure for each partition. A powerful security implication is that protection between partitions is implicit in the forwarding plane at a per-packet level. This is because SID acts as the separator between partitions and will not be switched within a domain. SID may also be used to simplify resource management because SID directly identifies the SP for each packet. The trade-off for these advantage is that global SID reduces the theoretical maximum number of LSPs supportable in the system. The SID space cannot be label-switched between LSRs, thus the capacity of possible LSPs supportable by the system is reduced. However, the maximum capacity of the system is still immense, because of the large 32 bit address space given to label switching and 24 bit address space for SID. Another disadvantage is that fixing the partitioning space is relatively inflexible. We expect that delegation of control will only be given to larger SPs and that 32 bits for each SP will be sufficiently scalable. Thus, the fixing of the partitioning space should not be a significant issue. C. Micro-Instructions Architecture APLS, LSRs and LERs must perform standard label operations that together form the behavior of label switching. These label operations can be further broken down into sequences of basic operations. These basic operations are termed microinstructions. A basic set of micro-instructions jigsaw together to form the label-switching operations. The set of basic micro-instructions consists of the following. • POP: pops a label from the top of the label stack. • PUSH: pushes a label onto the top of the label stack. • FWD: forwards the packet to the network interface. • DLV: delivers the packet to the IP layer. Sequences of micro-instructions form the following standard label operations.

Core switching: This is the operation of the core LSRs. First, the LSR pops the top label off the packet’s label stack and then uses the label to do the forwarding lookup. The resulting forwarding entry contains the outgoing label, and the network interface to use. The LSR then pushes the outgoing label onto the label stack and switches the packet to the network interface. Thus the sequence of micro-instructions is POP, PUSH, and FWD. • Ingress switching: This is the operation for packets entering APLS networks. The ingress LER decides which FEC to use for an incoming IP packet (routing decision). The FEC indicates the LSP to use; it includes the outgoing label and the network interface information. The LER will push the outgoing label onto the packet’s label stack and switch the packet to the network interface. Thus the sequence is PUSH and FWD. • Egress switching: This is the operation for packets reaching the end of the LSP. First, the LER pops the top label off the packet’s label stack and then delivers the packet to the IP layer for IP forwarding/routing. Thus the sequence contains POP and DLV. • Penultimate hop popping: Penultimate LSR refers to the LSR preceding the egress LER for the LSP. The Penultimate Hop Popping[5] operation is the same as that of Core Switching except no label will be pushed onto the packet’s label stack. Thus the sequence consists of POP and FWD. Similar use of micro-instructions by [12] is in the implementation level only and does not integrate this concept into the architecture design. The advantage of integration into the network design is the flexibility that can be achieved by micro-instructions. The APLS Micro-Instruction Architecture (AMIA) uses micro-instructions as the basis for customizing label operations at the fine-grain level of per-LSP in each LSR. An extended set of micro-instructions can be developed to give value-added mechanisms. For example, a set of microinstructions that does some form of forward error correction would be useful for paths that have high error rates. AMIA also serves as a cooperation point between APLS and other complementary technologies. A specific focus on cooperating with APN will be discussed later in Section V. •

D. Micro-Policy-Based Forwarding APLS offers a flexible multi-path routing and forwarding mechanism. Multi-path routing can be established by mapping more than one LSP to a Forwarding Equivalence Class (FEC). Multi-path forwarding can be established by mapping more than one outgoing label to an incoming label in a LSR. APLS proposes the use of Micro-Policies (MPs) for choosing a path on per-packet basis. That is, if multi-path exists, the MP will be used to decide the path to take for each packet. Perpacket decisions allow a fine granularity of control, but the MP must be lightweight enough to run at wire speed. Examples of MP are as follows. • First in List: This is useful when backup LSPs exist, but only one LSP is ever used at a time. • Round Robin: This is a simple load balancing scheme.

QoS: Using some of the EXP bits in the APLS label to determine which LSP to use. • Statistical: Using statistical data about the LSR or the LSPs to determine which path to use. This can be a powerful basis for dynamic forwarding adaptation. • Broadcast: Use all the outgoing labels. This is for multicasting. It is also possible to use MP functions that look into the IP header for additional information. For example, the DSCP field can be used by the QoS MP function. •

IV. C ONTROLLING APLS APLS offers a forwarding mechanism with a high degree of control and flexibility but it requires cooperation with other components to form a complete network. One essential component is the control architecture, which is responsible for functions such as label/route distribution, resource reservation, and traffic engineering. The simplistic scenario is to put together existing technologies such as APLS, LDP [13], DiffServ [1] and RSVPTE [14] with APLS to form a network. LDP distributes labels automatically and dynamically while RSVP-TE allows for manual traffic engineering control. A better approach requires the introduction of specialised control protocols that take advantage of APLS’s capabilities. We propose a Decision-Policy-based LDP (DP-LDP) that allows service providers to customise the decision making processes involving their labels. In DP-LDP, the decision policy associated with the VLS will be used to make decisions on such issues as the labels to distribute for this VLS and the labels to accept. A service provider will be able to select which policy to assign to the VLS. If APN is used to realize DPLDP, a possibility is to allow service providers to customise their own policy. Another approach was introduced by Merwe et al.[7]. They proposed multiple control architectures running on the same LSR. This allows service providers to deploy their own control architecture for their VLS, but requires heavy processing (memory and CPU) and networking (bandwidth) resources, and thus is not expected to scale. Therefore, only privileged service providers should be allowed to deploy their own control architecture. An alternative is for network providers to support a set of control architectures with each service provider choosing the one they want their VLS to use. Thus in this model, multiple service providers share a set of control architectures. V. APN OVER APLS APN offers the flexibility and control desired but not the performance and scalability. APLS offers a lesser degree of flexibility and control but provides the performance and scalability. The question is: What if we combine the two technologies? We envision a network model where selected traffic is given privileges for the less scalable special computations while the rest of the traffic is restricted to use the highly scalable APLS mechanisms. Our discussion is broken up into two parts. The

Using i-APN In Label Out Label 1:2:1 1:4:7

Inf 2 Micro-Instruction i-APN PUSH FWD

LSR B

In Label Out Label LSR 1:3:8 1:5:2 D Micro-Instruction PUSH FWD

Exit

Enter Ingress LER A FEC

Label

192.0.1.0

1:2:1

Inf 1

LSR C In Label Out Label 1:4:7 1:3:8

Micro-Instruction PUSH FWD

Fig. 3.

Inf 1

Inf 1

Egress LSR D In Label Out Label 1:5:2 Micro-Instruction DLV

Micro-Instruction i-APN

APN support in AMIA

first part discusses the various approaches that can be used for supporting APN over APLS. The second part focus on the network model that APN over APLS realises. A. APLS Support for APN APLS interfaces to APN through AMIA are provided by creating a new micro-instruction called i-APN, which indicates to APLS that the packets for this LSP in this LSR require special processing. When injecting i-APN into the sequence of micro-instructions that form the label operation, the iAPN instruction is associated with an APN handler. This handler will determine whether the packet requires special computation and if so which Execution Environment (EE) to use. EEs can be considered as environments processing different APN technologies or different instances of the same APN technology. If only one APN technology is supported then the entry point can be to service modules instead. We propose the LSP-oriented approach that associates APNs on a per-LSP per-LSR basis. This approach takes advantage of LSP’s scalability and requires a special protocol to set up LSP in LSRs to do special computation, i.e., this protocol will inject i-APN into the selected LSRs on the chosen LSP. Figure 3 illustrates APN Over APLS using the LSP-oriented approach. For each LSR on the LSP that is selected to do special APN computation, i-APN is injected into the label’s sequence of micro-instructions for that LSR. The sequence for the core LSR B would be: i-APN, PUSH, FWD. This sequence means that APN will do some content manipulation but would not override the APLS forwarding behavior. LSR C has only one micro-instruction i-APN, this means that the APN will override the forwarding behavior and thus will forward the packet itself. The LSP-oriented approach can control APN behavior at the granularity of per-LSR within each LSP. The result is that when setting up a LSP, it is possible to also set up the use of APN for that LSP. This incurs additional setup overhead but can eliminate the need for per-packet overhead. It is also possible to support per-hop approaches such as ANEP[15]. To support ANEP, every label operation must include i-APN, which invokes a handler that understands the semantics of the particular reference approach, e.g., a handler

that understands ANEP looks into IP’s protocol identifier field to check for ANEP packets. If the packet is ANEP, it will be passed to the ANEP module that further processes the packet, otherwise the packet will be label-switched as normal. B. APLS Network Model In APLS’s network model, the Network Provider (NP) core functions are to operate and maintain the network resource infrastructure. This infrastructure can consist of traditional QoS resources, such as bandwidth, or newer resources such as CPU and memory space in routers for APN. The NP in this model can also be the provider of Resource Facilities (RFs) at the edge of the network for heavy computation support. Service Providers (SPs) are given control of leased VLSs, therefore, they can now control the routing and forwarding behavior of their own traffic. By leasing resources from the NP, SPs can string resources together to create a service. For example, an online gaming SP can start a new service in the network by leasing servers from the RFs and creating LSPs to connect them together. The SP can then dynamically post available servers in the main server. If the SP notices bottlenecks in the network, it can select alternative LSPs to offload some traffic or use micro-policy-based multi-pathing to do load balancing. Using APN Over APLS, SPs can load instances of an execution environment, select LSPs, and associate the execution environment with them. Thus the SP has the privilege of doing special computation at the intermediate nodes inside the network rather than at the edge of the network. Examples of special computations are data adaptation [16], and data merging [17]. Similar network models [18], [7] have been proposed but none offers a solution that is as scalable and flexible as APN Over APLS. VI. DATA A DAPTATION E XAMPLE Various architectures [19], [20] have been proposed to provide adaptation of contents at intermediate network nodes using APN. Data adaptation is normally desired for transforming the content to fit into the receiving device, for example, transcoding video contents to play on a small mobile phone screen. The general concept is to have an Adaptation Server (AS) that does the data transformation before the data arrives at the destination device. A path must be set up from the source to the destination via the selected AS. One way to implement the path is to use UDP encapsulation. The UDP datagram that is destined for the client address is encapsulated in another UDP datagram, which is destined for the AS. The advantage for this method is its simplicity. However, the disadvantage is the additional 20 bytes of overhead. Another method is to implement a simple connection-oriented protocol on top of UDP. This requires an identifier (two bytes should be sufficient) for the connection and the extra connection state needed for mapping the identifier to the next hop. Thus the service requires a connection to be set up first and then the data is sent from the server in UDP datagrams that are destined for the AS. The AS will use the connection identifier to find the next hop destination, which is the client. The overhead is

Video Transcoding

object is transcoded and new data replaces the old payload. The UDP datagram then continues to be forwarded on the LSP until it reaches the client.

Request (TCP Connection) Client Video Server Video Object

UDP

frag

UDP

IP

APN

payload

IP

APN

payload

Ingress LER A

Fig. 4.

enter

IP

LSP

APN

payload

Video Object

Mod Video Object

Mod Video Object

UDP

IP

VII. C ONCLUSION UDP

resem

Buffers IP packets and reassemble UDP. Transcode video object.

LSP

LSR B AS setup

payload

exit

IP

payload

IP

payload

Egress LER C

i-APN Injected

Video transcoding example

APLS puts a new perspective into label-switching technology. While retaining the scalable performance of label switching, focus is put onto delegating control to the service providers and giving more flexibility to the network model. The use of micro-instructions delivers not only customisable label operations, but also offers an efficient way to use APN technologies over APLS. APN over APLS can effectively support the next generation networking environment that is expected to be service-oriented and dominated by IP traffic. We have built a prototype of APLS under Linux [21]. Details of the prototype can be found in [8]. R EFERENCES

reduced but complexity is increased for connection setup and management. The LSP-oriented approach proposed in Section V-A integrates the path with APLS LSP and retains label- switching semantics. In this method, the AS that can be used is restricted to LSRs on LSPs that forward the packet to the client. When setting up the AS on the LSP, the i-APN micro-instruction is injected into the label operation. The server sends the data in UDP datagrams destined for the client’s address. The UDP datagrams are fragmented if needed, enter the APLS network and are label-switched to the client. When a fragment arrives at the AS, the i-APN invokes the handler that identifies the active packet and passes it to the AS execution environment. When all the fragments have arrived, the UDP datagram is reassembled and the data is transformed by the AS. At this point the UDP datagram1 continues to be label-switched along the LSP until it reaches the egress point. Finally, the UDP datagram is IP-forwarded to the client. The benefits of this method include the following. • •

• •

No header overhead for the path; Path management is simplified as most work has already been done by APLS’s LDP. Path state overhead related to forwarding/routing is eliminated; End-to-end UDP semantics is retained; It is possible to hide the use of APN from the client if AS setup is server initiated.

However, the degree of freedom for path selection is restricted to the established LSPs that route to the client. Figure 4 shows an example of video transcoding using APLS with the LSP-oriented approach. The client sends a request for video streaming service using a TCP control connection. The request will include the UDP port on which the client expects to receive the data from the server. The server will then set up the AS on the service provider’s LSP that has a route to the client. At this stage, the server will send video objects in UDP datagrams and mark the datagrams as active packets. Once AS receives a UDP datagram, the video 1 The

UDP datagram may need to be fragmented.

[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An architecture for differentiated services,” IETF RFC 2475, 1998. [2] R. Braden, D. Clark, and S. Shenker, “Integrated services in the Internet architecture: an overview,” IETF RFC 1633, 1994. [3] G. Sackett and C. Metz, “ATM and Multiprotocol Networking,” McGraw Hill, 1997. [4] Z. Wang and G. Armitage, “Scalability Issues in Label Switching over ATM,” IETF Internet Draft, December 1997. [5] E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol Label Switching Architecture,” IETF RFC 3031, 2001. [6] W. Lau, S. Jha, and M. Hassan, “Current directions in Active Programmable Network,” in IEEE International Conference on Networks ICON, Bangkok, October 2001. [7] J. Merwe, S. Rooney, I. Leslie, and S. Crosby, “The Tempest - A practical Framework for Network Programmability,” IEEE Network, pp. 20–28, May/June 1998. [8] W. Lau and S. Jha, “Active Protocol Label Switching (APLS),” UNSW Technical Report 0207, ftp://ftp.cse.unsw.edu.au/pub/doc/papers/UNSW/0207.ps.Z, 2002. [9] Y. Rekhter, B. Davies, E. Rosen, G. Swallow, D. Farinacci, and D. Katz, “Cisco Systems’ Tag Switching Architecture overview,” IETF RFC 2105, 1997. [10] N. Feldman and A. Viswanathan, “ARIS specification,” IETF Internet Draft: draft-feldman-aris-spec-00.txt, 1997. [11] K. Coffman and A. Odlyzko, “Growth of the Internet,” AT&T Labs Research, July 2001. [12] J. R. Leu, “MPLS for linux,” http://mpls-linux.sourceforge.net/, 2002. [13] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas, “LDP Specification,” IETF RFC 3036, 2001. [14] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” IETF RFC 3209, 2001. [15] D. Alexander, B. Braden, C. Gunter, A. Jackson, A. Keromytis, and G. Minden, “Active Network Encapsulation Protocol,” http://www.cis.upenn.edu/˜switchware/ANEP/docs/ANEP.txt, 1997. [16] A. Fox, S. Gribble, Y. Chawathe, and E. Brewer, “Adapting to network and client variation using Active Proxies: Lessons and Perspectives,” A special issue of IEEE Personal Communications on Adapation, 1998. [17] D. Wetherall, D. Legedza, and J. Guttag, “Introducing new Internet services: why and how,” IEEE Network, pp. 12–19, May-June 1998. [18] F. Safaei, I. Ouveysi, M. Zukerman, and R. Pattie, “Carrier-scale programmable networks: Wholesaler platform and resource optimization,” IEEE JSAC, Vol 19, No. 3, March 2001. [19] A. Nakao, L. Peterson, and A. Bavier, “Constructing end-to-end paths for playing media objects,” in IEEE Open Architectures and Network Programming, 2001. [20] S. Gribble, M. Welsh, J. R. von Behren, E. Brewer, D. Culler, N. Borisov, S. Czerwinski, R. Gummadi, J. Hill, A. Joseph, R. Katz, Z. Mao, S. Ross, and B. Zhao, “The Ninja architecture for robust Internet-scale systems and services,” Computer Networks, vol. 35, no. 4, pp. 473–497, 2001. [21] W. Lau, “Linux-APLS Implementation Source,” http://review:[email protected]/˜wlau/apls.html, 2002.