y with the num- ber of separate RSVP reservations, and this results in a big scalability problem. RSVP signaling has evolved into a general-purpose signaling protocol for enterprise- based IP networks, applications, and services. Classic RSVP (described in RFC 2205) is for application-requested edge-to-edge QoS signaling. A router-based RSVP modification for MPLS traffic engineering, called RSVP Traffic Engineering (RSVP-TE), is specified under RFC 3209. RSVP-TE is in addi- tion to the RSVP protocol for establishing label-switched paths in MPLS networks. (MPLS is covered in Chapter 10.) RSVP-TE supports the instantiation of explicitly routed label-switched paths with or without resource reservations. It also supports smooth rerouting of label-switched paths, preemption, and loop detection. There are RSVP-TE extensions for fast restoration and extensions for Generalized MPLS. (GMPLS is discussed in Chapter 11.) Another new standard, called Aggregated RSVP, is specified under RFC 3175. Aggregated RSVP messages install an ingress-to-egress fat pipe. Normal RSVP mes- sage flow triggers the creation, expansion, or contraction of the ingress-to-egress fat pipe. Normal RSVP messages are forwarded edge to edge and ignored by inte- rior routers inside the aggregation region. Aggregated RSVP retains the edge-to- edge RSVP signaling paradigm but employs DiffServ forwarding and Aggregated RSVP signaling in the core network. RSVP Proxy is an extension to RSVP message processing currently in draft form at the IETF. In RSVP Proxy, an intermediate router responds, or proxies, a reservation Chapter 8 The Internet and IP Infrastructures message back to the sender. In this case, RSVP messages do not travel edge to edge as usual. Proxied reservation is generated under policy control. Applications can signal their presence and receive policy-based designation for special network treatment. Current QoS signaling is limited in scope and scale. Classic RSVP operates between hosts and routers but is absent in the greater Internet. RSVP-T