< draft-atlas-ospf-local-protect-cap-01.txt		draft-atlas-ospf-local-protect-cap-02.txt >
	Network Working Group A. Atlas, Ed.		Network Working Group A. Atlas, Ed.
	Internet-Draft Avici Systems, Inc.		Internet-Draft Google Inc.
	Expires: April 24, 2005 October 24, 2004		Expires: August 5, 2006 R. Torvi
			Avici Systems, Inc.
			G. Choudhury
			AT&T
			Juniper Networks
			D. Fedyk
			Nortel Networks
			February 2006
	U-turn Alternates for IP/LDP Fast-Reroute		OSPFv2 Extensions for Link Capabilities to support U-turn Alternates for
	draft-atlas-ospf-local-protect-cap-01.txt		IP/LDP Fast-Reroute
			draft-atlas-ospf-local-protect-cap-02
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 24, 2005.		This Internet-Draft will expire on August 5, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document proposes an extension to OSPF Version 2 for advertising		This document proposes an extension to OSPF Version 2 for advertising
	link capabilities using the extensions defined for traffic		link capabilities using the extensions defined for traffic
	engineering. The link capabilities are defined there for future		engineering. The link capabilities are defined there for future
	extensibility. To support the signaling requirements of U-turn		extensibility. To support the signaling requirements of U-turn
	alternates for IP Fast-Reroute, this document defines three bits in		alternates for IP Fast-Reroute, this document defines three bits in
	the proposed link capabilities extension.		the proposed link capabilities extension.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Link Capabilities sub-TLV . . . . . . . . . . . . . . . . . . 3		2. Link Capabilities sub-TLV . . . . . . . . . . . . . . . . . . . 3
	3. Interpretation for U-turn Alternates for IP Fast-Reroute . . . 4		3. Interpretation for U-turn Alternates for IP Fast-Reroute . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 5		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
	Contributing Authors' Addresses . . . . . . . . . . . . . . . 5		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . 7
	1. Introduction		1. Introduction
	The motivations for an extension to OSPF version 2 to allow		The motivations for an extension to OSPF version 2 to allow
	advertising link capabilities is to both allow the signaling required		advertising link capabilities is to both allow the signaling required
	by [U-TURN] and to provide for future extensibility.		by [U-TURN] and to provide for future extensibility.
	[RFC3630] specifies OSPFv2 Traffic Engineering extensions for		[RFC3630] specifies OSPFv2 Traffic Engineering extensions for
	carrying link attributes, via a new Link TLV which is carried in the		carrying link attributes, via a new Link TLV which is carried in the
	TE LSA. The Link TLV comprises of several sub-TLVs characterizing		TE LSA. The Link TLV comprises of several sub-TLVs characterizing
	the links. Among those sub-TLVs are the Link ID and Link Type sub-		the links. Among those sub-TLVs are the Link ID and Link Type sub-
	TLVs, which are the only mandatory sub-TLVs. This is the set of		TLVs, which are the only mandatory sub-TLVs. This is the set of
	information that is necessary to associated advertised link		information that is necessary to associated advertised link
	capabilities to the specific link. To avoid potentially unnecessary		capabilities to the specific link. To avoid potentially unnecessary
	redundant advertisement of the Link ID and Link Type, in the event		redundant advertisement of the Link ID and Link Type, in the event
	that a router needs to support signaling for both TE and link		that a router needs to support signaling for both TE and link
	capabilities, this document proposes adding a Link Capabilities		capabilities, this document proposes adding a Link Capabilities sub-
	sub-TLV to the Link TLV.		TLV to the Link TLV.
	The Link Capabilities sub-TLV is defined and three bits are		The Link Capabilities sub-TLV is defined and three bits are
	identified to support the signaling required by [U-TURN].		identified to support the signaling required by [U-TURN].
	2. Link Capabilities sub-TLV		2. Link Capabilities sub-TLV
	A new "Link Capabilities" sub-TLV is defined here to be carried in		A new "Link Capabilities" sub-TLV is defined here to be carried in
	the "Link" TLV which uses the TE LSA [RFC3630]. The Link		the "Link" TLV which uses the TE LSA [RFC3630]. The Link
	Capabilities field contains 32 flags, each indicating a different		Capabilities field contains 32 flags, each indicating a different
	link capability. The following flags are defined:		link capability. The following flags are defined:
	Bit Capability		Bit Capability
	0-3 Reserved		0-1 Reserved
	4 Eligible Alternate		2 Link excluded from local protection path
			3-4 Reserved
	5 Explicit Marked U-Turn Recipient Capable		5 Explicit Marked U-Turn Recipient Capable
	6 Implicit U-Turn Recipient Capable		6 Implicit U-Turn Recipient Capable
	7-31 Future assignments		7-31 Future assignments
	Following is the format for Link-ID sub TLV:		Following is the format for Link-ID sub TLV:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 10 | Length = 4 |		| Type = 10 | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Link Capabilities |		| Link Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3. Interpretation for U-turn Alternates for IP Fast-Reroute		3. Interpretation for U-turn Alternates for IP Fast-Reroute
	The OSPFv2 extensions described in this document define three bits		The OSPFv2 extensions described in this document define three bits
	which are relevant for determining the capabilities of a link in		which are relevant for determining the capabilities of a link in
	reference to U-turn Alternates for IP/LDP Fast-Reroute.		reference to U-turn Alternates for IP/LDP Fast-Reroute.
	If a link is advertised with a capability of "Eligible Alternate",		If a link is advertised as "link excluded from local protection
	then the router's neighbors are informed that the router considers		path", then the router's neighbors are informed that the router
	whether that link can be used as an alternate next-hop.		considers whether that link cannot be used as an alternate next-hop.
			For other applications, such as RSVP-TE FRR [RFC4090], this means the
			link SHOULD not be included in any computation of a repair path by
			any other router in the routing area.
	If a router's link is advertised as Implicit U-turn Recipient		If a router's link is advertised as Implicit U-turn Recipient
	capable, then the advertising router can apply the implicit U-turn		capable, then the advertising router can apply the implicit U-turn
	packet identification method[U-TURN] to identify packets as U-turn		packet identification method[U-TURN] to identify packets as U-turn
	packets and redirect those U-turn packets towards an appropriate		packets and redirect those U-turn packets towards an appropriate
	alternate next-hop, if such is available. A neighbor, which wishes		alternate next-hop, if such is available. A neighbor, which wishes
	to use this link as a U-turn alternate next-hop, should not mark		to use this link as a U-turn alternate next-hop, should not mark
	traffic sent on the link into a U-turn alternate.		traffic sent on the link into a U-turn alternate.
	If a router's link is advertised as Explicit Marked U-turn Recipient		If a router's link is advertised as Explicit Marked U-turn Recipient
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 38 ¶
	U-turn packet identification method[U-TURN] to identify packets as		U-turn packet identification method[U-TURN] to identify packets as
	U-turn packets and redirect those U-turn packets towards an		U-turn packets and redirect those U-turn packets towards an
	appropriate alternate next-hop, if such is available. A neighbor,		appropriate alternate next-hop, if such is available. A neighbor,
	which wishes to use this link as a U-turn alternate next-hop, should		which wishes to use this link as a U-turn alternate next-hop, should
	mark traffic sent on the link into a U-turn alternate.		mark traffic sent on the link into a U-turn alternate.
	4. IANA Considerations		4. IANA Considerations
	A new sub-TLV in the Link TLV will need to be assigned by IANA; this		A new sub-TLV in the Link TLV will need to be assigned by IANA; this
	is requested to be type 10, which is to be assigned via Standards		is requested to be type 10, which is to be assigned via Standards
	Action [RFC3630]. The remaining bits in the Link Capabilities		Action [RFC3630]. The remaining bits in the Link Capabilities sub-
	sub-TLV will need to be assigned by IANA.		TLV will need to be assigned by IANA.
	5. Security Considerations		5. Security Considerations
	This document does not introduce any new security issues.		This document does not introduce any new security issues.
	6 References		6. References
	[FRAMEWORK]
	Shand, M., "IP Fast Reroute Framework",
	draft-ietf-rtgwg-ipfrr-framework-02.txt (work in
	progress), October 2004.
	[IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute:		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	Loop-free Alternates",		(TE) Extensions to OSPF Version 2", RFC 3630,
	draft-ietf-rtgwg-ipfrr-spec-base-01.txt (work in		September 2003.
	progress), October 2004.
	[RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering		[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
	(TE) Extensions to OSPF Version 2", RFC 3630, September		Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	2003.		May 2005.
	[U-TURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute",		[U-TURN] Atlas, A., Ed., "U-turn Alternates for IP/LDP Fast-
	draft-atlas-ip-local-protect-uturn-01.txt (work in		Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work
	progress), October 2004.		in progress), February 2006.
	Editor's Address		Authors' Addresses
	Alia K. Atlas (editor)		Alia K. Atlas (editor)
	Avici Systems, Inc.		Google Inc.
	101 Billerica Avenue		1600 Amphitheatre Parkway
	N. Billerica, MA 01862		Mountain View, CA 94043
	USA		USA
	Phone: +1 978 964 2070		Email: akatlas@alum.mit.edu
	EMail: aatlas@avici.com
	Contributing Authors' Addresses
	Raveendra Torvi		Raveendra Torvi
	Avici Systems		Avici Systems, Inc.
	101 Billerica Avenue		101 Billerica Avenue
	N. Billerica, MA 01862		N. Billerica, MA 01862
	USA		USA
	Phone: +1 978 964 2026		Phone: +1 978 964 2026
	EMail: rtorvi@avici.com		Email: rtorvi@avici.com
	Gagan Choudhury		Gagan Choudhury
	AT&T		AT&T
	Room D5-3C21		Room D5-3C21
	200 Laurel Avenue		200 Laurel Avenue
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	EMail: gchoudhury@att.com		Phone: +1 732 420 3721
	Phone: +1 732 420-3721		Email: gchoudhury@att.com
	Christian Martin
	Verizon
	1880 Campus Commons Drive
	Reston, VA 20191
	EMail: cmartin@verizon.com
	Brent Imhoff		Brent Imhoff
	LightCore		Juniper Networks
	14567 North Outer Forty Rd.		1194 North Mathilda
	Chesterfield, MO 63017		Sunnyvale, CA 94089
	USA		USA
	EMail: brent@lightcore.net		Phone: +1 314 378 2571
	Phone: +1 314 880 1851		Email: bimhoff@planetspork.com
	Don Fedyk		Don Fedyk
	Nortel Networks		Nortel Networks
	600 Technology Park		600 Technology Park
	Billerica, MA 01821		Billerica, MA 01821
			USA
	EMail: dwfedyk@nortelnetworks.com
	Phone: +1 978 288 3041		Phone: +1 978 288 3041
			Email: dwfedyk@nortelnetworks.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 7, line 41 ¶		skipping to change at page 8, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 29 change blocks.
	77 lines changed or deleted		71 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/