ip over optical networks - a framework - internet engineering task
TRANSCRIPT
1 IETF 7/31/00
IP over Optical Networks - A Frameworkdraft-ip-optical-framework-01.txt
Bala RajagopalanJames Luciani
Daniel AwducheBrad Cain
Bilel Jamoussi
2 IETF 7/31/00
About this Draft
• Deals with the following issues:– IP transport over optical networks– IP-centric control plane for optical networks (MP?S-based)
• Defines terminology• Describes the optical network model• Describes service models• Describes architectural alternatives• Defines requirements• Proposes an evolution path for IP over Optical capabilities
3 IETF 7/31/00
Outline
• Network and service models• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures• IP-centric control plane issues• Conclusion
4 IETF 7/31/00
Outline
• Network and service models– Network Model– Domain Services Model– Unified Services Model
• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures• IP-centric control plane issues• Conclusion
5 IETF 7/31/00
IP over Optical: Model
OpticalSubnet
OpticalSubnet
OpticalSubnet
Router Network
Other Network
Router Network
Optical Network
End-to-end path (LSP)
Optical Path
IF1
IF2
6 IETF 7/31/00
Service Models: Domain Services Model
• Optical network provides well-defined services (e.g., lightpath set-up)• IP-optical interface is defined by actions for service invocation• IP and optical domains operate independently; need not have any routing
information exchange across the interface• Lightpaths may be treated as point-to-point links at the IP layer after set-up
Optical Cloud
Router Network Router Network
Service Invocation InterfacePhysical connectivity
7 IETF 7/31/00
Domain Services Model: Lightpath Set-Up
1. Decision to establish lightpath (e.g., offline TE computations)2. Request lightpath set-up. 3. Internal optical network signaling4. Lightpath set-up requested at destination 5. Lightpath set-up accepted6. Internal optical network signaling 7. Successful lightpath set-up
Optical Cloud
Router Network Router Network
1
2 3 4
567
8 IETF 7/31/00
Service Models: Unified Service Model
• IP and optical network treated as a single integrated network for control purposes• No distinction between IF1, IF2 and router-router (MPLS) control plane• Services are not specifically defined at IP-optical interface, but folded into end-to-end
MPLS services.• Routers may control end-to-end path using TE-extended routing protocols deployed in
IP and optical networks.• Decision about lightpath set-up, end-point selection, etc similar in both models.
Router Network Router Network
9 IETF 7/31/00
Unified Service Model: End-to-End Path Set-Up
1. Trigger for path set-up (e.g., TE decision)2. End-to-end path computation (may use previously declared Fas, or visibility
into optical network topology)3. Forward signaling for path set-up4. Reverse signaling for path set-up
1
34
2
10 IETF 7/31/00
Outline
• Network and service models• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures• IP-centric control plane issues• Conclusion
11 IETF 7/31/00
IP over Optical Services Evolution Scenario
• Definition of capability sets that evolve• First phase: Domain services model realized using appropriate MP?S signaling
constructs
Optical Cloud(with or w/ointernal MP?Scapability)
Router Network Router Network
MP?S-based signaling forservice invocation, No routing exchange
12 IETF 7/31/00
Evolution Scenario (contd.)
• Second phase: Enhanced MP?S signaling constructs for greater path controloutside of the optical network. Abstracted routing information exchangebetween optical and IP domains.
Optical Cloud(withinternal MP?Scapability)
Router Network Router Network
MP?S-based signaling forservice invocation (enhanced). Abstractedrouting information exchange
13 IETF 7/31/00
Evolution Scenario (Contd.)
• Phase 3: Peer organization with the full set of MP?S mechanisms.
MP?S-based signaling for end-to-end path set-up.MP?S-based signaling within IP and optical networks.Full routing information exchange.
Optical networkRouter network
14 IETF 7/31/00
Outline
• Network and service models• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures• IP-centric control plane issues• Conclusion
15 IETF 7/31/00
The Role of MP?S
• This framework assumes that MP?S will be the basis for supporting differentIP over optical service models
• Main expectations:– Define signaling and routing mechanisms for accommodating IP over
optical network service models– Define representations for addressable entities and service attributes
• Realize above within the framework of requirements for different servicemodels
• Define a clear set of mechanisms for each set of (increasingly sophisticated)capabilities required
• Accommodate an evolution path for service capabilities
16 IETF 7/31/00
Outline
• Network and service models• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures
– Architectural alternatives– Routing approaches
• IP-centric control plane issues• Conclusion
17 IETF 7/31/00
IP over Optical Networks: Architectural Models
• Architectural alternatives defined by control plane organization– Overlay model (loosely coupled control planes)– Augmented model (loosely coupled control planes)– Peer model (tightly coupled control planes)
• Routing approaches– Integrated routing (peer model)– Domain-specific routing (augmented model)– Overlay routing (overlay model)
18 IETF 7/31/00
Integrated Routing: OSPF
• Entire client-optical network treated as single network. Both client and optical networksrun same version of OSPF protocol
• Client devices (routers) have complete visibility into optical network• Clients compute end-to-end path• Client border devices must manage lightpaths (bandwidth allocation, advertisement of
virtual links, etc.)• Determination of how many lightpaths must be established and to what endpoints are
traffic engineering decisions
R1
R2R3
R4
R5O1 O2
O3
,
Network N1 Network N2Network N3
19 IETF 7/31/00
Domain-Specific Routing: BGP
• Client network sites belong to a VPON. Client border devices and borderOXCs run E-BGP. Routing in optical and client networks can be different
• BGP/MPLS VPN model defined in draft-rosen-rfc2547bis-02.txt may beapplied
• Determination of how many lightpaths must be established and to whatendpoints are traffic engineering decisions
R1
R2R3
R4
R5O1 O2
O3
x.y.a.*,x.y.b.*
a.b.c.*
x.y.c.*
Network N1 Network N2Network N3
EBGPEBGP
IBGP
20 IETF 7/31/00
Overlay Routing
• Each client border router registers its address (and VPON id) with the optical network• Optical network allows other client border routers belonging to the same VPON to
query for addresses.• IP routers establish lightpaths and run a routing protocol on the overlay topology• Determination of how many lightpaths must be established and to what endpoints are
traffic engineering decisions
R1
R2R3
O2
O3 R4
R5
VPON 1VPON 1
x.y.z.1
a.b.c.1
Registration Message
Reachability Message
<x.y.z.1, 1>
<a.b.c.1, 1>
<a.b.c.1, 1><x.y.z.1, 1>
<x.y.z.1, 1>
<a.b.c.1, 1>
Registration Service
<a.b.c.1, 1><x.y.z.1, 1>
21 IETF 7/31/00
Outline
• Network and service models• IP over Optical network services evolution• The role of MP?S• IP over Optical network architectures• IP-centric control plane issues• Conclusion
22 IETF 7/31/00
IP-centric Control Plane: Main Issues
• Control procedures within and between sub-networks aredistinguished.
• MP?S control plane is assumed. Issues considered:– Identification– Neighbor discovery– Topology discovery– Restoration models– Route computation– Signaling issues– Optical internetworking
23 IETF 7/31/00
Identification
• Termination point identification in optical networks– Possible structure: Node, Port, Channel, Sub-channel
• Trail segment identification between adjacent OXCs– MP?S labels with the required structure (e.g., port, channel, sub-
channel)• SRLG Identifiers: Flat identifiers?
24 IETF 7/31/00
Neighbor Discovery
• To determine the local link connectivity between adjacent OXCs– Serves as the first step towards topology discovery– Required for specifying MP?S labels over optical links
• Neighbor discovery over opaque and transparent links– Procedures TBD– LMP is referred as a possibility
25 IETF 7/31/00
Topology Discovery
• Link state protocol recommended• Bundling recommended to reduce number of adjacencies and links
represented• Bundling structure is TBD.• The encoding of restoration-related parameters for computing shared
protection paths is TBD
26 IETF 7/31/00
Route Computation & Signaling
• Route computation with SRLG constraints is discussed• Signaling issues described
– Bi-directional lightpaths– Fault-tolerance– Signaling for restoration
27 IETF 7/31/00
Optical Internetworking
OpticalSubnet
Requirements discussed:• Common, global addressing scheme for optical path endpoints• Propagation of reachability information• End-to-end path provisioning using signaling• Policy support (accounting, security, etc)• Support for subnet-proprietary provisioning and restoration algorithms
28 IETF 7/31/00
Optical Control Plane: Restoration
Multi-domain restoration:• Allow possibility of proprietary restoration in each subnetwork• Specify an overall end-to-end restoration scheme as backup.• Signaling and routing for end-to-end restoration
29 IETF 7/31/00
Conclusion
• The draft gives a high-level overview of IP over Optical servicemodels and architectures
• Recommends an evolutionary approach to IP over optical, startingfrom simple capabilities and going to more sophisticated capabilities
• IP over Optical requirements not yet defined in the framework– Domain services model requirements available
• Restoration issues require further discussion• IP over optical traffic engineering issues need coverage