E is edge-to-edge for traffic engineering. RSVP does not cross administrative domains, nor does it really traverse different technology regimes such as wireless or support mobility. An IETF working group has therefore been chartered to develop the requirements, architec- tures, and protocols for expanding and extending QoS signaling across the Inter- net, and a new architecture called NSIS is emerging. The design goals of NSIS include applicability across different QoS technolo- gies, such as DiffServ and MPLS, as well as resource availability upon request prior to a reservation request. NSIS is modular in design. It involves the decoupling of the protocol and the information carried within it. It allows reuse of existing QoS provisioning, where appropriate, and it provides independence between signaling and provisioning mechanisms. As shown in Figure 8.29, the NSIS architecture QoS Domain Subdomain Subdomain Signaling Signaling QoS Subdomain QoS Subdomain QI = QoS initiator QC = QoS control Figure 8.29 NSIS What's Next on the Internet includes a QoS service class, which specifies QoS requirements of a flow or traffic aggregate. It also includes QoS signaling, which conveys the QoS service class into the network. A QoS initiator triggers QoS signaling. QoS control interprets and acts on QoS signaling messages in the network. RSVP version 2 (RSVPv2) defines a lighter version of RSVP signaling that addresses the NSIS requirements. It has been designed to coexist with RSVPvl and have efficient core functionality, with service-specific extensibility. RSVPv2 allows for unicast operation, and it is sender oriented and soft-state based. It has multiple service specifications, and it accommodates raw IP transport. What's Next on the Internet An interesting way to consider what's next on the Internet, or in ICT in general, is to play a game that Vinton Cerf, one of the heralded fathers of TCP/IP and the Internet, is fond of introducing in his presentations. He calls it the "Fifty Year Game." It goes like this: "Let's go b