Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
Extracted elements (24)
A single end-to-end RSVP session is used for the UNI user connection, with the first and last hops constituting the UNI. This carries user parameters end-to-end and obviates any mapping between UNI parameters and the NNI format used within the Service Provider network, satisfying the ASON requirement that UNI and NNI be independent.
In optical networks, deletion of a connection (e.g., removal of a cross-connect) may cause downstream nodes to perceive a failure (loss of frame, loss of light), triggering management alarms and potentially unwanted protection/restoration. The ADMIN_STATUS graceful deletion procedure addresses this by pre-signaling the intent to delete.
In the overlay model, core-nodes act as a closed system: edge-nodes do not participate in the core routing protocol and are unaware of core topology. This contrasts with the peer model where edge-nodes and core-nodes share the same routing and signaling protocol interactions.
Multiple overlay networks supported by a single core network may use one or more address spaces according to privacy requirements. This can be achieved without varying core-node addresses since it is the <edge-node, core-node> tuple that constitutes address space membership.
A core-node adjacent to an edge-node MAY map between teardown using ResvTear/PathTear and PathErr with Path_State_Removed. A core-node receiving a ResvTear from its downstream neighbor MAY respond with a PathTear and send a PathErr with Path_State_Removed further upstream.
All RSVP-TE signaling procedures for GMPLS UNI in the overlay model are identical to the GMPLS extensions specified in RFC 3473, except as explicitly noted in this document. The extensions are compatible with GMPLS signaling defined in RFC 3471 and RFC 3473.
The UNI extensions are designed to be compatible with the ASON architecture (ITU-T G.8080). When both UNI and NNI are GMPLS RSVP-based, the methodology allows for a single RSVP session to instantiate both UNI and NNI signaling if desired and permitted by Service Provider policy.
A core-node MAY edit the RRO in a Resv message such that it includes only the subobjects from the egress core-node through the egress edge-node, allowing the ingress node to learn the selected link and labels at the far end of the connection without exposing core topology.
A core-node next to an edge-node receiving a PathErr with Path_State_Removed from its downstream neighbor MUST NOT retain Path state and send a ResvTear further upstream, because that would imply Path state further downstream had also been retained.
An edge-node MAY include a NOTIFY_REQUEST object in Path and Resv messages. A core-node MAY remove a NOTIFY_REQUEST object received from an edge-node before forwarding it. If the core-node updates the Notify Node Address with its own address, Notify messages MAY be selectively forwarded to the edge-node based on local policy.
An edge-node MAY include an ERO in a Path message. A core-node MAY reject a Path message containing an ERO; if it does, it SHOULD return a PathErr with error code 'Unknown object class' as described in RFC 3209.
An edge-node MAY include an RRO. A core-node MAY remove the RRO from the Path message before forwarding it, and MAY also remove the RRO from a Resv message before forwarding it to the edge-node. Such behavior is controlled by configuration.
For alarm-free connection deletion, the graceful deletion procedure SHOULD be followed: an ADMIN_STATUS object MUST be sent in a Path or Resv message along the connection's path to inform all nodes of the intended deletion prior to the actual deletion.
If an ingress core-node receives a PathTear without having first seen an ADMIN_STATUS object indicating impending deletion, it MAY pause the PathTear and first send a Path message with ADMIN_STATUS. When the Resv echoing ADMIN_STATUS is received, or upon timer expiry per RFC 3473, the ingress core-node MUST forward the PathTear.
If no NOTIFY_REQUEST object is present in Path or Resv from an edge-node, the adjacent core-node may include one set to its own address; in either case the core-node SHOULD NOT send Notify messages directly to the edge-node.
When a core-node receives a Path message from an edge-node containing an ERO, it SHOULD verify the route against its topology database. If the route is not viable (topology, available resources, or policy), a PathErr with error 24,5 should be returned.
When GMPLS is used for the core network, it is RECOMMENDED that VPN connections use the procedure based on MPLS-HIER (RFC 4206), where the core connection is signaled first and then referenced via an IF_ID RSVP_HOP object when forwarding the original Path message within the VPN addressing realm.
An edge-node is identified by either a single IP address representing its Node-ID or by one or more numbered TE links connecting it to core-nodes. Core-nodes are assumed ignorant of any edge-node addresses not used in signaling connections through the GMPLS core.
Edge-node and adjacent core-node must share the same address space used by GMPLS to signal between edge-nodes across the core. A set of <edge-node, core-node> tuples share an address space if edge-nodes can establish LSPs among themselves without address mapping or translation.
To support explicit label control and full egress link identification, an ingress edge-node may include explicit control information as the only hop of the ERO: the first subobject is set to the node-ID of the egress core-node with the L-bit set, followed by subobjects identifying the link and labels.
VPN connections are modeled as three hops: one for each access link and one hop across the core network. The VPN connection is established using a two-step procedure where the core connection is set up as a separate signaling exchange between core-nodes before the original Path message is forwarded.
When forming a SENDER_TEMPLATE, the ingress edge-node includes either its Node-ID or the address of one of its numbered TE links; using a TE link address restricts the connection to that specific interface.
When forming a SESSION_OBJECT, the ingress edge-node includes either the Node-ID of the egress edge-device or the address of one of the egress' numbered TE links. The Extended_Tunnel_ID of the SESSION Object is set to either zero or an address of the ingress edge-device.
The trust model between core and edge-nodes differs from RFC 3473: the core is permitted to hide its topology from edge-nodes, and the core is permitted to restrict edge-node actions by filtering out specific RSVP objects. Realization of the UNI must meet functional requirements for robustness, security, and privacy.