Transcript Internet QoS for IPv6

CCAMP WG of the 58th IETF Meeting
(Other Draft)
Jun-Hyun, Moon
Computer Communications LAB.,
Kawangwoon University
[email protected]
Communicaton of Alarms
draft-berger-ccamp-gmpls-alarm-spec-00.txt
L. Berger (Movaz), D. Brungard (ATT), I. Bryskin (Movaz)
A. Farrel (Old Dog Consulting), D. Papadimitriou (Alcatel)
A. Satyanarayana (Movaz)
2
The Not-A-Tutorial Slide

Pleased note:
 The function described does not replace or modify any
existing management plane function

Provides alarm information along full LSP
Node 172.16.25.6, IP Interface 1.1.3.2
Severity : Major, Condition: DATALOL
Time : NOV 01 21 : 11 : 09 2003
Node 172.16.25.12, IP Interface 1.1.2.1
Severity : Critical, Condition: LOS
Time : NOV 01 20 : 52 : 15 2003
3
Open Issues

Non-Issues
 Enabling/disabling alarm information communication
 Uses new Admin_Status Bit
 Communication of alarm information
 Uses new Alarm_Spec object with same format as Error_Spec,
plus new TLVs
 Not modifying LSP state
 Alarm_Spec sent in path and Resv messages
 Compatibility

Two Open Issues
 Use of new TLVs in Error_Spec
 Error codes for well knows and standard Alarms
4
Issues (Continued)

Should the use of new the TLVs in Error_Spec be
allowed?
 Four new TLVs





Reference_count
Severity
Timestamp
Error_string
Code points for well known and standard Alarms
 To be carried in Error Values using new Error Codes
 Identified ITU and Telecordia specs use string not values
 Options:
 Define string to value mapping for some/every spec
 Punt, i.e., stay with using strings
5
New Steps


Resolve open issues
Progress the draft
 Does this fit into the charter?
 WG document?
6
Generized MPLS Signaling for Layer-2 LSPs
draft-papadimitriou-ccamp-gmpls-l2sc-lsp-00.txt
D.Papadimitriou (Alcatel), D.Brungard (ATT),
M.Vigoureux (Alcatel)
7
Why?

Goal : RFC 3473 support of L2SC LSPs
 L2 switching architecture : [X, L2SC], … , [L2SC, L2SC], … ,
[L2SC, X] where X = Any (in particular, PSC)
 Layered switching architectures (FA LSP’s) : [L2SC, Y], … , [Y,
L2SC] where Y = Any (in particular, TDM or LSC)

Non-Goal : PW architecture (~ provisioned overlays
over PSN)
8
L2SC LSP and Setup Methods


L2SC LSP => “tunnel” for Ethernet payload transport
w/o necessarily using MPLS PW’s and other extended
p2p LDP signaling
Method for e2e LSP Setup




Direct e2e LSP setup
LSP nesting (FA-LSP in network)
LSP stitching (LSP Segment in network)
LSP shuffling (~ GMPLS VPN)
9
LSP Nesting & Stitching/Shuffling
10
What do we need?




Not that much … since max re-use of existing GMPLS
RFC’s
Get agreement on GPID’s e.g. GFP, X.86
Get agreement on label semantic(s) e.g. Port, Flow,
VLAN
Get agreement on bandwidth encoding (any
enhancement from current TSPEC ?)
=> Support from the working group to refine GMPLS
procedures for L2SC LSPs?
11
Component Link Recording and Resource
Control for GMPLS Link Bundles
draft-zamfir-exmplicit-resource-controlbundle-02.txt
Anca Zamfir, Zafar Ali (Cisco Systems),
D. Papadimitriou (Alcatel)
12
Motivation and Contribution

Resource within bundled TE link is specification by [TE
Link ID, Component interface ID, Label value]

Label Recording

 Label RRO (RFC 3209
RFC 3473)

Component Link
recording Also desirable for
diagnostics purposes (and for
applications that can make use
of this information)
Explicit Label Selection
 Label ERO (RFC 3473)
 Used for LSP splicing but
not sufficient MUX/DEMUX
capable component link of
bundled TE Links

Explicit component link
selection for application like
“LSP splicing” and for selecting
component link of desired
SRLG attribute
13
Update from Last IETF




Update the I-D based on WG feedback
Email follow-up on/off the list that show fair interest in
RRO extension for component link recording
Component link recording independent of label
recording (backward compatibility) using either LSP
Attribute or Session_Attribute Flags (to be discussed)
Editorial and text improvement
14
Next Step


Next revision to include more details on motivations
and direct applications (add introductory section)
Request the CCAMP WG to accept this I-d as a WG
document
15
Expedited Flooding for Restoration in
Shared-Mesh Transport Networks

draft-rabbat-expedited-flooding-00
 Richard Rabbat (FLA)
 Vishal Sharma (Metanoia, Inc.)
 Zafar Ali (Cisco)

Observations
 This work complementary to P&R team output
 Captures all private and ML discussion and resolutions


Highlights time-bounded notification requirements for
transport networks
Discusses mitigating factors to ensure no network
meltdowns
16
Expedited Flooding

Describes types of failure
 Fiber cut
 Transponder failure
 Node failure


Applies whether one adapts a link-state routing protocol
behavior or implementing a new flooding mechanism
Reasoning behind using an expedited flooding protocol
 Points out the advantages of flooding
 Discusses approach to avoid network meltdowns
 Sending messages on first try happens immediately
 Retry attempts in the case of failure force a delay (using OSPF
hold down timer or timers associated with new mechanism)
17
Expedited Flooding

Next Steps
 We have received a lot of feedback on flooding-based
notification
 Need to advance draft to WG document since fits in charter
18