1. An introduction to MPLS and GMPLS (and briefly T-MPLS)
Anne-Grethe Kåråsen, Telenor R&I
Modified by Steinar Bjørnstad NTNU
Two slides on T-MPLS added by Norvald Stol NTNU 2007

2. Why was MultiProtocol Label Switching (MPLS) designed?
To enhance the performance of the traffic forwarding mechanisms (compared to traditional IP forwarding)
To provide a traffic engineering (TE) capability in IP networks

3. What is Traffic Engineering (TE)?
TE is concerned with performance optimization of operational networks.
Traffic performance: A major goal of Internet TE is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance.
QoS: Traffic oriented performance objectives include the aspects that enhance the QoS of traffic streams.
Resource utilization: Resource oriented performance objectives include the aspects pertaining to the optimization of resource utilization.
Minimizing congestion is a primary traffic and resource oriented performance objective. The interest here is on congestion problems that are prolonged rather than on transient congestion resulting from instantaneous bursts. Congestion typically manifests under two scenarios:
- When network resources are insufficient or inadequate to accommodate offered load.
- When traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized.
The first type of congestion problem can be addressed by either: (i) expansion of capacity, or (ii) application of classical congestion control techniques, or (iii) both.  
The second type of congestion problems, namely those resulting from inefficient resource allocation, can usually be addressed through Traffic Engineering.
Traffic oriented performance measures include delay, delay variation, packet loss, and throughput.

4. The resource problem to solve:
Conventional IGP path computation is selected based upon a simple additive metric.
Bandwidth availability is not taken into account
Some links may be underutilized while others are congested.

5. A solution to the resource problem
Path for R1 to R3 traffic
Path for R2 to R3 traffic

6. MPLS - some main concepts
Uses label switching to forward data
A label is a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.
MPLS path = Label Switched Path (LSP)
Forwarding Equivalence Class (FEC)
A group of IP packets that are forwarded in the same manner
FEC – label mapping in ingress MPLS node
Criteria for assigning packets to FECs are configurable
Next Hop Label Forwarding Entry (NHLFE)
Packets next hop + label operation (swap, push, pop)
Label swapping gives a service provider tremendous flexibility in the way that it assigns packets to FECs. For example, to simulate conventional IP forwarding, the ingress label switch can be configured to assign a packet to an FEC based on its destination address. However, packets can also be assigned to an FEC based on an unlimited number of policy-based considerations—the source address alone, the application type, the point of entry into the label-swapping network, the point of exit from the label-swapping network, the CoS conveyed in the packet header, or any combination of the above.
The most important benefit of the label-swapping forwarding algorithm is its ability to take any type of user traffic, associate it with an FEC, and map the FEC to an LSP that has been specifically designed to satisfy the FEC’s requirements.

7. The MPLS shim header
The EXP Field is "Experimental" though it is proposed use is to indicate Per Hop Behavior of labeled packets traversing Label Switching Routers. (QoS)
The Stack (S) Field indicates the presence of a label stack.
The Time to Live Field is decremented at each LSR hop and is used to throw away looping packets.

8. LSP route determination
An LSP must be set up and labels assigned at each hop before traffic forwarding can take place.
There are two kinds of LSPs, based on the method used for determining the route:
control-driven LSPs (hop-by-hop LSPs)
explicitly routed LSPs (ER-LSPs)
A control-driven LSP follows the path that a packet using default IP routing would have used.
An ER-LSP may be specified and controlled so that the network traffic follows a path independent of what is computed by IP routing.

9. Constraint-based routing
Types of constraints:
Resource related (e.g. bandwidth)
Administrative (e.g. include/exclude certain links)
Resource related and policy related attributes are associated with links.
Link attributes are flooded by the routing protocols along with topology information.
A constraint-based path computation process uses this information when finding paths that satisfy given constraints.
Most used algorithm is Constraint Shortest Path First (CSPF):
Excludes all links that fail to meet constraint
Chooses shortest path that meets constraint
Convenient for online path selection, one LSP at a time

10. ER-LSPs
Explicit LSP: route is determined at the originating node. When we explicitly route an LSP, we call it an LSP tunnel or a traffic-engineering tunnel.
Explicit route information is carried only at the time of LSP setup, not with each packet forwarded on the LSP.
LSP tunnels are uni-directional.
Can be set up manually or by the use of a signaling protocol.
LSPs can be designed to minimize the number of hops, meet certain bandwidth requirements, support precise performance requirements, bypass potential points of congestion, direct traffic away from the default path selected by the IGP, or simply force traffic across certain links or nodes in the network.

11. ER-LSP setup example using RSVP-TE
RSVP Path message carried Explicit Route Object (ERO)
RSVP Resv message carries Label information (L)
LSR8
LSR2
LSR6
LSR3
LSR4
LSR7
LSR1
LSR5
LSR9
ERO=(2, 6, 7, 4, 5)
ERO=(6, 7, 4, 5)
ERO=(7, 4, 5)
ERO=(4, 5)
ERO=( 5)
L=21
L=10
L=14
L=5
Analogue process for CR-LDP: LABEL REQUEST message downstream and LABEL MAPPING message upstream

12. MPLS Label Forwarding Example
LABEL SWITCHING
IP Forwarding IP
Packet
Label 1
Label 2
Label 3
Label-Switched Path (LSP)
LER
LSR

13. Label stacking

14. Protocols for MPLS routing and signaling
Open Shortest Path First (OSPF) & Intermediate System –Intermediate System (IS-IS) with TE extensions
Signaling:
Label Distribution Protocol (LDP) [RFC 3036]
Constraint based LDP (CR-LDP) [RFC 3212]
Extensions to Resource Reservation Protocol (RSVP) for LSP tunnels [RFC 3209]
Border Gateway Protocol (BGP) [RFC 3107]

15. MPLS references
Multiprotocol Label Switching Architecture, RFC 3031, Jan 2001
Requirements for traffic engineering over MPLS, RFC 2702, Sept 1999
Traffic engineering extensions to OSPF version 2, RFC 3630, September 2003
Traffic Engineering Extensions to OSPF version 3, Internet Draft <draft-ietf-ospf-ospfv3-traffic-07>, April 2006
IS-IS extensions for traffic engineering, RFC 3784, June 2004
LDP specification, RFC 3036, Jan 2001
Constraint-based LSP setup using LDP, RFC 3212, Jan 2002
RSVP-TE: Extensions to RSVP for LSP tunnels, RFC 3209, Dec 2001
Carrying label information in BGP-4, RFC 3107, May 2001

16. Generalized MultiProtocol Label Switching (GMPLS)
GMPLS is an enhanced version of the MPLS-concept.
GMPLS related work is coordinated by the IETF Common Control and Measurement Plane (ccamp) working group.
In data networks, MPLS covers both the control plane (label binding, label distribution, etc.) and the data plane (packet forwarding).
In circuit switched networks there is no packet forwarding.
Only MPLS control plane components are applicable to circuit switched networks.
GMPLS assumes IP-based routing and signaling protocols, and IP addresses. (IP-centric)

17. GMPLS (former MPlS) – mapping to OTN
Main features applicable to OTN (Optical Transport Network)
MPLS control plane is implemented in each OXC
Constraint-based routing and signaling provide control plane for OXCs
to discover, distribute, and maintain relevant state information associated with the OTN
to establish and maintain OCh trails
Each OXC is considered an equivalent of a Label Switched Router (LSR)
Lightpaths (OCh trails) are considered similar to Label Switched Paths (LSPs)
Lambdas and switch ports are considered similar to labels

18. GMPLS – new set of LSP interfaces
Packet Switch Capable (PSC) interfaces:
Recognize packet boundaries and can forward data based on the content of the packet header (IP header, MPLS shim header).
Layer-2 Switch Capable (L2SC) interfaces:
Recognize frame/cell boundaries and can forward data based on the content of the frame/cell header (Ethernet MAC header, ATM VPI/VCI).
Time-Division Multiplex Capable (TDM) interfaces:
Forward data based on the data’s time slot in a repeating cycle (SDH/SONET, G.709 TDM, PDH).
Lambda Switch Capable (LSC) interfaces:
Forward data based on the wavelength on which the data is received (wavelength, waveband).
Fiber-Switch Capable (FSC) interfaces:
Forward data based on a position of the data in the real world physical spaces (port, fiber).

19. GMPLS control plane – functional components
Resource discovery and link management
The transaction that establishes, verifies, updates and maintains the LSR adjacencies and their port pair association for their transport (data) plane.
LSR level resource table: resource map that includes attributes, neighbor identifiers, and real-time operation states.
Routing
Topology information dissemination
Path selection
Signaling
LSP creation, modification, deletion, restoration, and exception handling
For conventional IP networks, there is no separated control plane network because control and user data traffics share the same network. For circuit based networks, an independent DCN is a fundamental requirement because a typical circuit switch doesn't process user data traffic in its transport plane. In order for GMPLS control plane to be applicable to circuit based networks, the DCN concept MUST be introduced. The DCN supporting GMPLS control plane may use different types of physical mediums:
The control traffic could be carried over a communication channel embedded in the data-carrying circuit link between LSRs. For example, the medium could be SONET/SDH or OTN overhead bytes.
The control traffic could be carried over a separate communication channel that shares the physical link with the data channels. For example, the medium could be a dedicated wavelength, a STS-1 or a DS-1.
The control traffic could be carried over a dedicated communication link between LSRs, separate from the data-bearing links. For example, the medium could be a dedicated LAN or a point to point link.
GMPLS control plane requirements for DCN:
The DCN supporting the GMPLS control plane MUST support IP.
The DCN should provide communications (either directly or in-directly) between any pair of LSRs that need control traffic exchanging.
The DCN must be secure.
The DCN must be reliable and provide fault-tolerance.
DCN should support message forwarding priority functionality.
The DCN should be extensible and scalable.
Control plane DCN inter-working is the first step towards control plane integration. It is desirable to have a common control plane DCN architecture and protocol stack so that control planes of different networks could communicate with each other.

20. GMPLS – LSR level resource discovery and link management
Self resource awareness/discovery
As a result, the LSR resource table is populated with local ID, physical attributes, and logical constraints parameters
Neighbor discovery and port association
The process of discovering the status of local links to all neighbors by each LSR in the network, The up/down status of each link, link parameters, and the identity of the remote end of the link must be determined (periodical operation) [LMP].
Resource verification and monitoring
Neighbor operation state detection and configuration verification (continuous operation).
Service negotiation/discovery
Covers all aspects related to service rules/policy negotiation between neighbors.
Examples of physical attributes are signal type, payload type, optics types etc. Several physical attributes can be abstracted into one logical attribute. Meanwhile, logical attributes may not be assigned to a particular physical port directly, instead, they may describe characteristics of a physical port pool. Examples of logical attributes are: VPN ID, SRLG (Shared risk link group)[OPT-BUND] and Service type.
Furthermore, a LSR might have different types of neighbors. Its physical adjacent neighbor may not be its switching neighbor. For example, two OXCs could be inter-connected through DWDM transmission systems in the middle. These two OXCs are switching neighbors even though they are not physically adjacent. So a LSR may maintain several local LSR level resource tables. The GMPLS control plane only cares about resource tables of a LSR's switching neighbors. Other LSR level resource tables may be used for fault management, inventory management etc.
Neighbor discovery would typically require in-band communication on the bearer channels to determine local connectivity and link status.
Service negotiation essentially covers all aspects of service-related rules/policy negotiation between neighbors. A typical example is the negotiation of rules for label binding and assignment. In this case, neighbors build up a label-binding and look-up table according to the physical connectivity map.

21. GMPLS - Routing Topology information dissemination
Distribution of topology information through the network to form a consistent network level resource view among LSRs.
What type of information is required?
How is the information disseminated?
Triggering mechanisms for information update?
GMPLS assumes that an IP-based routing protocol is used for topology information dissemination.
GMPLS extensions have been defined for the TE extended versions of OSPF and IS-IS.
There are several aspects of the state information dissemination process that are still under study, such as:
-     what type of information is required, especially related to the path selection process, e.g.
link identifier, status and corresponding signal encoding
link bandwidth (min/max reservable bandwidth and available bandwidth)
link protection type (if applicable)
shared risk link group (SRLG)
-      how is the information disseminated, e.g. by the use of an IGP (distributed) or some other protocol (centralised or distributed)
-     triggering mechanisms for information update, taking the following facts into consideration:
Some information is static (e.g. SRLG), while some information is rather dynamic (e.g. available bandwidth).
When building the initial network topology database, all information needs to be disseminated.
Subsequently, as long as static information remains unchanged, only the dynamically changing information needs to be flooded.
A consequence of the above may be that static information change requires immediate information flooding, while the flooding of dynamic information is triggered by some threshold mechanism.
To ensure that network topology information is consistent throughout the network, a total information flooding should take place periodically.

22. GMPLS – Routing cont. Path selection
Usually a constraint-based computation process, resulting in an explicit route or source route.
Hop-by-hop routing is also possible.
Specific constraints on optical layer routing
Re-configurable (but blocking) network elements such as OADMs
Transmission impairments
Absence of wavelength conversion
Path diversity
The switching capability of the OADMs may be constrained. For example:
There may be some wavelengths that can not be dropped at all.
There may be a fixed relationship between the frequency dropped and the physical port on the OADM to which it is dropped.
OADM physical design may put an upper bound on the number of adaptation groupings dropped at any single OADM.

23. GMPLS - IGP Extensions
OSPF and IS-IS extensions to carry additional information:
switching capabilities of link (PSC, L2SC, TDM, LSC, FSC)
link encoding (e.g. SONET, SDH, GbE, etc.)
grouping of links that share same fate (SRLG)
protection capabilities of link
incoming and outgoing interface ID
CSPF extensions:
take into account new constraints (e.g. link encoding, multiplexing capabilities, etc.)
compute diverse paths
compute bi-directional paths
Link protection capabilities:
Extra Traffic: the link is protecting another link or links. The LSPs on a link of this type will be lost if any of the links it is protecting fail.
Unprotected: there is no other link protecting this link. The LSPs on a link of this type will be lost if the link fails.
Shared: there are one or more disjoint links of type Extra Traffic that are protecting this link. These Extra Traffic links are shared between one or more links of type Shared.
Dedicated 1:1: there is one dedicated disjoint link of type Extra Traffic that is protecting this link.
Dedicated 1+1: a dedicated disjoint link is protecting this link. However, the protecting link is not advertised in the link state database and is therefore not available for the routing of LSPs.
Enhanced: a protection scheme that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS-SPRING, is being used to protect this link.
SRLG:
The SRLG information is an unordered list of SRLGs that the link belongs to. Each SRLG is identified by a 32 bit number that is unique within the IGP domain. The SRLG of a bundled link is the union of the SRLGs of all the component links.

24. GMPLS - Signaling GMPLS inherits all signaling functions from MPLS-TE:
LSP creation
LSP deletion
LSP modification
LSP exception handling
Additional GMPLS signaling protocol requirements:
Creation of bi-directional LSPs
Support of unnumbered links
Rapid failure notification
LSP fast restoration

25. GMPLS – signaling extensions
Generalized label request
Supports communication of characteristics required to support the LSP being requested, including LSP encoding, switching type, and LSP payload
LSP bandwidth encoding values, carried in a per protocol specific manner (e.g. in the CR-LDP Traffic Parameters TLV)
Generalized label
Extends the traditional label by allowing the representation of labels that identify time-slots, wavelengths, or space division multiplexed positions, or “anything that is sufficient to identify a traffic flow”.
Non-hierarchical label.
Support of waveband switching
A waveband represents a set of contiguous wavelengths that can be switched together to a new waveband.
Waveband label contains 3 fields: waveband ID, start label, end label.
Suggested label
Is used to provide a downstream node with the upstream node's label preference.
May reduce latency of LSP setup
GMPLS generalizes the request setup message for two reasons: to distinguish it from a non-generalized request setup, and to allow it to carry additional parameters that specify the request in more detail. In RSVP this is done by using a Generalized Label Request object instead of a LABEL_REQUEST in the Path message, and in CR-LDP by adding a Generalized Label Request TLV to the Label Request message.
The LSP Encoding Type indicates the encoding type that will be used with the data associated with the LSP, i.e. the type of technology being considered. For instance, it can be SDH, SONET, Ethernet, ANSI PDH, etc. It represents the nature of the LSP, and not the nature of the links that the LSP traverses.
A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats. The Switching Type indicates then the type of switching that should be performed on a particular link for that LSP. This information is needed for links that advertise more than one type of switching capability.
The LSP payload type (G-PID) identifies the payload carried by the LSP, i.e. an identifier of the client layer of that LSP. For some technologies it also indicates the mapping used by the client layer.
Other technology specific parameters are not transported in the Generalized Label Request but in technology specific traffic parameters.
Bandwidth encoding does not apply to SONET/SDH and G.709, for which the traffic parameters fully define the requested SONET/SDH or G.709 signal.
Generalized MPLS extends the representation of a label from a single 32 bit number to an arbitrary length byte array and introduces the Generalized Label object (in RSVP) and Generalized Label TLV (in CR-LDP) to carry both the label itself and related information.
The Suggested Label is used to provide a downstream node with the upstream node's label preference. This permits the upstream node to start configuring it's hardware with the proposed label before the label is communicated by the downstream node. Such early configuration is valuable to systems that take non-trivial time to establish a label in hardware. Such early configuration can reduce setup latency, and may be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.

26. GMPLS – signaling extensions cont.
Label set
Is used to limit the label choices of a downstream node to a set of acceptable labels.
Explicit label control
Ingress LSR may specify the label(s) to use on one, some or all of the explicitly routed links for the forward and/or reverse path.
Bi-directional symmetric LSP
A symmetric bi-directional LSP has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements in each direction.
Downstream and upstream data paths are established using a single set of signaling messages.
New Upstream Label Object/TLV
Rapid notification of failure and events
Acceptable Label Set for notification on label error
Expedited notification (RSVP-TE only)
Link protection
Protection Information Object/TLV indicates:
The desired link protection for each link of an LSP
Whether the LSP is a primary or secondary LSP
The Label Set is constructed by including and/or excluding an arbitrary number of label lists and/or ranges. If no labels are explicitly included, the set consists of all valid labels not explicitly excluded. If no Label Set is present, the downstream LSR is not constrained in its choice of label. As the Label Set is propagated on the Path message, each LSR may generate a new outgoing Label Set, based on its hardware capabilities and possibly on the incoming Label Set. For example, an LSR that is incapable of wavelength conversion generates an outgoing Label Set by forwarding the incoming Label Set, minus any labels that it cannot generate or receive. In contrast, an LSR that is capable of converting all wavelengths in an incoming Label Set may choose to remove the Label Set when sending the signaling request downstream, to indicate that it will accept any label for use on its downstream link. A label set is composed of one or more Label_Set objects/TLVs.
Explicit label control is useful, for example, when the ingress LSR wants to insist that the wavelength used is the same along the whole LSP. This might be desirable in order to avoid distortion of the optical signal. Explicit labels are specified by the ingress LSR as part of the explicit route. At each LSR along the path, any explicit label that is specified in the explicit route for the next hop is removed and converted into a Label Set object, containing a single label, for the next hop. The LSR that receives this Label Set is then required to use this label for that hop
Extensions to RSVP-TE enable expedited notification of failures and other events to determined nodes. For CR-LDP there is not currently a similar mechanism. The first extension identifies where event notifications are to be sent. The second provides for general expedited event notification with a Notify message. Such extensions can be used by fast restoration mechanisms. Notifications may be requested in both the upstream and downstream directions.

27. GMPLS – LSP Protection and restoration
So far, only intra-area, intra-layer P&R mechanisms for handling single failure scenarios are being discussed.
Protection schemes:
1+1 link protection
1:N or M:N link protection
Enhanced protection
1+1 LSP protection
Restoration schemes:
End-to-end LSP restoration with re-provisioning
End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and no label pre-selection
End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and label pre-selection
Local LSP restoration
1+1 Link Protection: Two pre-provisioned resources are used in parallel. For example, data is transmitted simultaneously on two parallel links and a selector is used at the receiving node to choose the best source.
1:N Link Protection: Working and protecting resources (N working, 1 backup) are pre-provisioned. If a working resource fails, the data is switched to the protecting resource, using a coordination mechanism (e.g. in overhead bytes). More generally, N working and M protecting resources can be assigned for M:N link protection.
Enhanced Protection: Various mechanisms such as protection rings can be used to enhance the level of protection beyond single link failures to include the ability to switch around a node failure or multiple link failures within a span, based on a pre-established topology of protection resources.
1+1 LSP Protection: Simultaneous data transmission on working and protecting LSPs and tail-end selection can be applied.
End-to-end LSP restoration with re-provisioning: An end-to-end restoration path is established after failure. The restoration path may be dynamically calculated after failure, or pre-calculated before failure (often during LSP establishment). Importantly, no signaling is used along the restoration path before failure, and no restoration bandwidth is reserved. As a result, there is no guarantee that a given restoration path is available when a failure occurs. Thus one may have to crankback to search for an available path.
End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and no label pre-selection: An end-to-end restoration path is pre-calculated before failure and a signaling message is sent along this pre-selected path to reserve bandwidth, but labels are not selected. The resources reserved on each link of a restoration path may be shared across different working LSPs that are not expected to fail simultaneously. Local node policies can be applied to define the degree to which capacity is shared across independent failures. Upon failure detection, LSP signaling is initiated along the restoration path to select labels, and to initiate the appropriate cross-connections.
End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and label pre-selection: An end-to-end restoration path is pre-calculated before failure and a signaling procedure is initiated along this pre-selected path on which bandwidth is reserved and labels are selected. Resources reserved on each link may be shared across different working LSPs that are not expected to fail simultaneously. In networks based on TDM, LSC and FSC technology, LSP signaling is used after failure detection to establish cross-connections at the intermediate switches on the restoration path using the pre-selected labels.
Local LSP restoration: the above approaches can be applied on a local basis rather than end-to-end, in order to reduce recovery time.

28. GMPLS extensions to the MPLS control plane – a summary
Support of devices that perform switching in the time, wavelength and space domain.
Use of label stacking and the resulting LSP interface hierarchy
The concept of link bundling
The new Link Management Protocol (LMP) for automatic link configuration and control
Computation of physically disjoint paths by use of Shared Risk Link Group (SRLG).
The establishment of bi-directional symmetric LSPs
The traditional IP routing model assumes the establishment of a routing adjacency for each link between adjacent nodes. Technologies like WDM result in a large number of parallel links between adjacent nodes. To solve this obvious scalability problem, the concept of link bundling is introduced. This allows multiple parallel links between two nodes to be advertised as a single link into the routing protocol (IGP). The component links in a link bundle must have the same link type, TE metric, set of resource classes (colours), and link multiplex capability (packet, TDM, l, port).
Another extension made to deal with the scalability problem is the use of unnumbered links. Unnumbered links are links that do not have IP addresses. Instead, unnumbered links are uniquely identified within the scope of the node (LSR) to which they belong, i.e. the upstream (originating) LSR.

29. (multiplex low-order LSPs) (demultiplex low-order LSPs)
GMPLS - LSP hierarchy
LSC
TDM
PSC
Bundle
Fiber n
Fiber 1
FSC Cloud
Cloud
Explicit
Label LSPs
Time-slot
LSPs
Fiber LSPs
l LSPs
(multiplex low-order LSPs)
(demultiplex low-order LSPs)
Nesting LSPs enhances system scalability
LSPs always start and terminate on similar interface types
LSP interface hierarchy
Packet Switch Capable (PSC) Lowest
Layer 2 Switch Capable (L2SC)
Time Division Multiplexing Capable (TDM)
Lambda Switch Capable (LSC)
Fiber Switch Capable (FSC) Highest

30. GMPLS - Link Bundling
Bundled Link 1
Bundled Link 2
Allows multiple parallel links between nodes to be advertised as a single link into the IGP
Enhances IGP and traffic engineering scalability
Component links must have the same:
Link type
Traffic engineering metric
Set of resource classes (colors)
Link multiplex capability (packet, TDM, λ, port)
(Max bandwidth request)  (bandwidth of a component link)
Admission control is applied on a per-component link basis
A TE link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnect LSRs into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling.
Depending on the nature of resources that form a particular TE link, for the purpose of GMPLS signaling in some cases a combination of <link identifier, label> is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, a combination of <link identifier, label> is not sufficient. Such cases are handled by using the link bundling construct.
The link bundling construct assumes that the set of resources that form the TE link could be partitioned into disjoint subsets, such that (a) the partition is minimal, and (b) within each subset a label is sufficient to unambiguously identify the appropriate resources used by an LSP. We refer to such subsets as "component links", and to the whole TE link as a "bundled link". On a bundled link a combination of <(bundled) link identifier, component link identifier, label> is sufficient to unambiguously identify the appropriate resources used by an LSP.
All component links in a bundle must begin and end on the same pair of LSRs, have the same Link Type (i.e., point-to-point or multi-access), the same Traffic Engineering metric, and the same set of resource classes at each end of the links.

31. GMPLS references
Optical Network Service Requirements, Internet Draft <draft-ietf-ipo-carrier-requirements-05>, December 2002
Generalized Multi-Protocol Label Switching (GMPLS) Architecture, RFC 3945, October 2004
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003
Routing extensions in support of generalized MPLS, RFC 4202, October 2005
LSP hierarchy with generalized MPLS TE, RFC 4206, October 2005
Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON), RFC 4139, July 2005
Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON), RFC 4258, November 2005

32. GMPLS references cont.
OSPF extensions in support of generalized MPLS, RFC 4203, October 2005
IS-IS extensions in support of generalized MPLS, RFC 4205, October 2005
Generalized Multi-Protocol Label Switching (GMPLS) signaling – Constraint-based routed label distribution protocol (CR-LDP) extensions, RFC 3472, January 2003
Generalized Multi-Protocol Label Switching (GMPLS) signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions, RFC 3473, January 2003
Link management protocol (LMP), RFC 4204, October 2005
Impairments and other constraints on optical layer routing, RFC 4054, May 2005
Shared risk link groups inference and processing, Internet Draft <draft-papadimitriou-ccamp-srlg-processing-02>, June 2003

33. GMPLS technology specific references
Framework for GMPLS-based control of SDH/SONET networks, RFC 4257, December 2005
Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control, RFC 3946, October 2004
Generalized MPLS (GMPLS) signaling extensions for G.709 optical transport networks control, RFC 4328, January 2006
Traffic engineering extensions to OSPF for Generalized MPLS control of Sonet/SDH networks, Internet Draft <draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01>, February 2003
Traffic engineering extensions to OSPF for Generalized MPLS control of G.709 optical transport networks, Internet Draft <draft-gasparini-ccamp-gmpls-g709-ospf-00>, November 2002

34. ITU-T Recommendations
G.8080 Architecture for the Automatic Switched Optical Network (ASON) (06/2006)
G.7712 Architecture and Specification of Data Communication Network (03/2003)
G.7713 Distributed Call and Connection Management (DCM) (05/2006)
G Distributed call and connection management (DCM) based on PNNI (03/2003)
G Distributed Call and Connection Management: Signaling mechanism using GMPLS RSVP-TE (03/2003)
G Distributed Call and Connection Management: Signaling mechanism using GMPLS CR-LDP (03/2003)
G.7714 Generalized automatic discovery for transport entities (08/2005)
G.7715 Architecture and Requirements for Routing in the Automatic Switched Optical Networks (06/2002)
G ASON routing architecture and requirements for link state protocols (02/2004)
G.807 describes the network level requirements for the control plane of automatically switched transport networks (ASTN).
G.8080 specifies the architecture and requirements for the automatic switched transport network as applicable to SDH transport networks, as defined in G.803, and Optical Transport Networks, as defined in G.872.
G.7712 defines the architecture requirements for a Data Communications Network (DCN) which may support distributed management communications related to the Telecommunications Management Network (TMN), distributed signalling communications related to the Automatic Switched Transport Network (ASTN), and other distributed communications.
G.7713 provides the requirements for the distributed call and connection management for both the User Network Interface (UNI) and the Network Node Interface (NNI).
G provides the protocol specifications for the distributed call and connection management for both the User Network Interface (UNI) and the Exterior Network Node Interface (E-NNI) based on PNNI/Q.2931.
G provides the protocol specifications for the distributed call and connection management for both the User Network Interface (UNI) and the Exterior Network Node Interface (E-NNI) based on GMPLS RSVP-TE (proposed by Cisco, Lucent, etc.)
G.7714 describes the specifications for automatic discovery techniques to aid resource management and routing.
G.7715 specifies the requirements and architecture for the routing functions of the switched connections (SC) and the soft permanent connections (SPC) within the framework of the Automatic Switched Transport Networks (ASTN). It also covers the network resource inventory management functions.

35. Optical Internetworking Forum (OIF) Implementation agreements
User Network Interface (UNI) 1.0 Signaling Specification, October 2001
User Network Interface (UNI) 1.0 Signaling Specification, Release 2: Common Part, February 2004
RSVP Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2, February 2004
Intra-carrier E-NNI Signaling Specification, February 2004
The service discovery procedure is a precursor to obtaining UNI services. Service discovery allows a client to determine the static parameters of the interconnection with the network, including the UNI signaling protocol, the type of concatenation, the transparency level as well as the type of diversity (node, link, SRLG) supported by the network.

36. Transport-MPLS (T-MPLS)
Standardized by ITU-T for application in transport part of network only.
Simplified MPLS: all features not necessary for connection-oriented applications are removed, i.e. less complex operation and more easily managed than MPLS.
Management principles are adopted from existing standards/practice, e.g. from SONET/SDH.
Supports - engineered point-to-point bi-directional LSPs, - end-to-end LSP protection, and - advanced OAM.
Goal is to provide reliable packet-based technology (MPLS) in a form that is aligned with circuit-based transport networking.

37. T-MPLS (2) Differences from MPLS:
Use of bi-directional LSPs traversing the same links and nodes.
No LSP merging option. (Multipoint-to-point is allowed in MPLS, as in IP). Not allowed in pure connection oriented network.
No Equal Cost Multiple Path (ECMP) option. Not needed in connection-oriented network.
No Penultimate Hop Popping (PHP) option. Label must be present in last node.
(See whitepaper by TPACK: ”Transport-MPLS A New Route to Carrier Ethernet” for overview – or standards).