< draft-minaburo-rohc-nemo-00.txt		draft-minaburo-rohc-nemo-01.txt >
	NEMO A. Minaburo		NEMO A. Minaburo,ENST-B.
	Internet Draft ENST-Bretagne		Internet Draft E.K. Paik, KT
	Document: draft-minaburo-rohc-nemo-00.txt E.K. Paik		Document: draft-minaburo-rohc-nemo-01.txt L. Toutain, ENST-B.
	KT		J-M. Bonnin, ENST-B.
	L. Toutain		Expires: January 2006 July 2005
	ENST-Bretagne
	Expires: September 2005 March 2005
	ROHC (Robust Header Compression) in NEMO network		ROHC (Robust Header Compression) in NEMO network
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 3 of RFC 3667 [1]. By submitting this		all provisions of Section 3 of RFC 3667 [1]. By submitting this
	Internet-Draft, each author represents that any applicable patent or		Internet-Draft, each author represents that any applicable patent or
	other IPR claims of which he or she is aware have been or will be		other IPR claims of which he or she is aware have been or will be
	disclosed, and any of which he or she become aware will be disclosed,		disclosed, and any of which he or she becomes aware will be
	in accordance with RFC 3668.		disclosed, in accordance with Section 6 of BCP 79.
	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 Internet-		other groups may also distribute working documents as 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 August, 2005.		This Internet-Draft will expire on January, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document defines the use of ROHC header compression mechanisms		This document defines the use of ROHC header compression mechanisms
	for the NEMO Basic Support protocol [9]. The idea is to use both		for the NEMO Basic Support protocol [7]. The idea is to use both NEMO
	NEMO and ROHC as they have been defined without any change. The		and ROHC as they have been defined. In the NEMO Basic Support
	tunneling in the NEMO Basic Support protocol will be done over		protocol, the tunneling between the Mobile Router (MR) and the Home
	different supports (Wireless LAN, 3G or PPP) links, where ROHC		Agent (HA) of the MR is done over different access technologies. Some
	compression can work.		of these technologies are wireless (e.g. Wireless LAN, 3G or PPP) and
			have scarce resources by nature, the use of ROHC compression can be
			useful to reduce the bandwidth consumption.
	Conventions used in this document		Conventions used in this document
	In examples, "C:" and "S:" indicate lines sent by the client and		In examples, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [ ].		document are to be interpreted as described in RFC-2119 [1].
	Table of Contents		Table of Contents
	1. Introduction 2		1. Introduction 2
	2. The use of ROHC in NEMO 2		2. The use of ROHC in NEMO 3
	3. ROHC configuration 4		2.1 Basics 3
	4. NEMO addresses 4		2.2 ROHC operation modes 3
	4.1 Addresses for header compression 4		2.3 ROHC compressor 4
	Security Considerations 5		2.4 ROHC decompressor 4
	References 5		2.5 ROHC work in progress 4
	Acknowledgments 6		3. ROHC Configuration 5
	Author's Addresses 6		3.1 Tunneling Encapsulation 5
	Copyright Statement 6		3.2 ROHC packet Format 6
			3.3 Negotiation Header Packets 7
			3.4 ROHC Parameter Values 10
			3.5 ROHC Profiles 10
			4. Modifications to NEMO Basic Support 10
			4.1 Home Agent Operation 11
			4.2 Mobile Router Operation 11
			4.3 Use of Addresses 11
			IANA Considerations 11
			Security Considerations 11
			References 11
			Author's Addresses 12
			Change Log 13
	1. Introduction		1. Introduction
	Network mobility (NEMO) [1] is concerned with managing the mobility		The Network mobility (NEMO) Basic support [7] has been designed to
	of an entire network through a mobile router (MR). The MR dynamically		manage the mobility of an entire network. A Mobile Router (MR) in
	changes its point of attachment to the Internet. ROHCs header		this network manages the connectivity between different access
	compression algorithms are able to reduce the header size and		networks and the mobile networks. It is responsible to change its
	improve performance in low bandwidth links. This document defines the		point of attachment each time it is needed and to maintain a tunnel
	use of ROHC [2,3,4,5,6,7,8] mechanisms in a NEMO network [9] to		(IP/IP) to its Home Agent (HA). This tunnel allows correspondent
	improve the performance between the home agent and the mobile router.		nodes and mobile nodes attached to the mobile network to act as if
			the mobile network was physically connected to its home network
	Section 2 introduces where ROHC will be used in NEMO, section 3 will		beside the HA.
	describe the ROHC configuration and section 4 will describe the use		Due to the IP tunneling a double header is needed between the MR and
	of NEMO addresses for header compression.		the HA, including the low bandwidth link between the MR and the
			access network.
			ROHCs header compression algorithms are known to be able to reduce
			the header size and to improve performance in low bandwidth links.
			This document defines how to use ROHC [2,3,4,5] mechanisms in a NEMO
			network [7] to reduce the overhead and therefore to improve the
			performance between the HA and the MR.
			The Handover produced when the MN moves does not affect the ROHC
			compression performance, the only problem that can be found is the
			disordering reception of packets, when the MN moves a new tunnel
			between the MR and the HA will be created, packets of the old tunnel
			can arrive later.
			Section 2 explains where ROHC will be used in NEMO architecture,
			section 3 describes the ROHC configuration in this context and
			section 4 describes the use of NEMO encapsulation for header
			compression.
	2. The use of ROHC in NEMO		2. The use of ROHC in NEMO
	A basic approach of using ROHC in mobile networks is to use		2.1 Basics
	bi-directional tunnel between the MR and HA to preserve session
	continuity while the MR moves. As ROHC has been defined to work
	between two peers, the header compression of ROHC will be done
	between the MR and the HA tunneling.
	As tunneling in NEMO Basic Support [9] is bi-directional, ROHC will		A basic approach of using ROHC in mobile networks context is to use
			ROHC to compress the header of IP packet traveling inside the
			bi-directional tunnel established between the MR and HA. This tunnel
			has some useful properties: it preserves the session continuity while
			the MR moves and headers of IP packets traveling inside the tunnel do
			not depend on the mobility of the mobile network.
			The MR has two different interfaces, the ingress interfaces are
			connected to the mobile network and the egress interfaces are
			connected to the access network. An IP tunnel (often with IPSec) is
			established between the egress interface and the HA. The HA has to
			route packets that belong to the mobile network prefix to the MR
			through the IP tunnel. The MR, on its side, has to route the packet
			issued by the mobile network to the HA through the tunnel.
			ROHC header compression is applied to packets issued by the mobile
			network just after the routing decision and before the IP
			encapsulation. The same thing is done by the HA on the other way.
			As tunneling in NEMO Basic Support [7] is bi-directional, ROHC will
	be able to perform the three operation modes and use the feedback to		be able to perform the three operation modes and use the feedback to
	improve performance.		improve performance.
			Figure 1. ROHC in NEMO
			ingress +-----+egress +-----+
			+----------+ | MR |-----------------------------------| HA |
			| IP packet| ---|+----| IPv6/IPsec(ESP)/ROHC or IPv6/ROHC |----+|
			+----------+ ||ROHC|-----------------------------------|ROHC||
			+-----+ +-----+
	ROHC mechanism for RTP, UDP, IP and UDP-Lite flows works by removing		ROHC mechanism for RTP, UDP, IP and UDP-Lite flows works by removing
	the redundancy and transfers only changing fields. It classifies the		the redundancy and transfers only changing fields. It classifies the
	header fields into static and dynamic fields. Static fields are those		header fields into static and dynamic fields. Static fields are those
	that remain constant during the lifetime of the packet and dynamic		that remain constant during the lifetime of the packet and dynamic
	fields are those that keep on changing but their change pattern may		fields are those that keep on changing but their change pattern may
	be known.		be known.
			2.2 ROHC Operation modes
	ROHC has three operation modes: Unidirectional (U), bi-directional		ROHC has three operation modes: Unidirectional (U), bi-directional
	Optimistic (O) and bi-directional Reliable (R). The U-mode is used		Optimistic (O) and bi-directional Reliable (R)(See RFC 3095 section
	when the link is unidirectional or when feedback is not possible. For		4.4). The U-mode is used when the link is unidirectional or when
	bi-directional links we can use the O-mode or the R-mode. The O-mode		feedback is not possible. For bi-directional links we can use the
	sends only negative feedbacks, optionally it can also send positive		O-mode or the R-mode. The O-mode sends only negative feedbacks,
	feedbacks but the R-mode uses both negative and positive feedbacks.		optionally it can also send positive feedbacks but the R-mode uses
	ROHC always starts header compression using U-mode even if it is		both negative and positive feedbacks. ROHC always starts header
	used in a bi-directional link.		compression using U-mode even if it is used in a bi-directional link.
			2.3 ROHC Compressor
	The ROHC compressor removes the redundant header fields and the		The ROHC compressor removes the redundant header fields and the
	redundant information in the packet flow. ROHC compression		redundant information in the packet flow. ROHC compression
	communicates changing fields most of the time. While sending the		communicates changing fields most of the time. While sending the
	fields that change, it further achieves efficiency by using an		fields that have changed, it further achieves efficiency by using an
	encoding algorithm in which only the last significant bits are sent.		encoding algorithm (See RFC 3095 section 4.5) in which only the last
	The ROHC compressor has three compression levels: Initialization and		significant bits are sent.
	Refresh (IR), First Order (FO) and Second Order (SO). In IR
	compression level it establishes the static information and in FO
	compression level the change pattern of dynamic fields. In the last
	compression level, SO, it sends encoded values of Sequence Number
	(SN) and Timestamp (TS) forming the minimal size packets. With the
	use of this header format packet all header fields can be generated
	at the other end of the link using the previously established change
	pattern. When some updates or errors are there, the compressor goes
	back to the upper compression levels. It only returns to the SO
	compression level after retransmitting the updated information and
	establishing again the change pattern in the decompressor.
	The decompressor works at the receiving end of the link and		The ROHC compressor has three compression levels (See sections RFC
	decompresses the headers based on the header fieldsÆ information of		3095 5.3, 5.4 and 5.5): Initialization and Refresh (IR), First Order
	the context. Both the compressor and the decompressor use a context		(FO) and Second Order (SO). In IR compression level it establishes
	to store all the information about the header fields. To ensure		the static information and in FO compression level the change pattern
	correct decompression, the context should be synchronized all the		of dynamic fields. In the last compression level, SO, it sends
	time. The decompressor has three states, the first is No Context (NC)		encoded values of Sequence Number (SN) and Timestamp (TS) forming the
	that is when there is no context synchronization, and the second is		minimal size packets. With the use of this header format packet (See
	Static Context (SC) that is reached only after the dynamic		section 5.7 RFC 3095) all header fields can be generated at the other
	information in the context is lost. The third is Full Context (FC),		end of the link using the previously established change pattern. When
	reached when the decompressor has all the information about header		some updates or errors are there, the compressor goes back to the
	fields. When in FC state, the decompressor moves to the initial		upper compression levels. It only returns to the SO compression level
	states as soon as it detects context damage. It uses the k out of n		after retransmitting the updated information and establishing again
	rule by looking at the last n packets, if CRC failures have occurred		the change pattern in the decompressor.
	for at least k packets then, it assumes context damage and transits
	backward to an initial state. The decompressor also sends feedback		2.4 ROHc Decompressor
	according to the operation modes.
			The decompressor works at the receiving end of the link (See RFC 3095
			section 5.3.2) and decompresses the headers based on the header
			fields' information of the context. Both the compressor and the
			decompressor use a context to store all the information about the
			header fields. To ensure correct decompression, the context should
			be synchronized all the time. The decompressor has three states, the
			first is No Context (NC) that is used when there is no context
			synchronization, and the second is Static Context (SC) that is
			reached if the dynamic information in the context has been lost. The
			third is Full Context (FC), reached when the decompressor has all the
			information about header fields. In FC state, the decompressor moves
			to the initial states as soon as it detects context damage. It uses
			the k out of n rule by looking at the last n packets, if CRC failures
			have occurred for at least k packets then, it assumes context damage
			and transits backward to an initial state. The decompressor also
			sends feedback according to the operation modes.
	The Decompressor manages the operation mode in which the system will		The Decompressor manages the operation mode in which the system will
	work through the use of mode transitions that allow it to change from		work through the use of mode transitions (See RFC 3095 section 5.6)
	one mode to another, based on the link characteristics and the		that allow it to change from one mode to another, based on the link
	performance requirements. The decompressor also uses some efficient		characteristics and the performance requirements. The decompressor
	schemes to correct the context when it gets damaged or the		also uses some efficient schemes to correct the context when it gets
	synchronization gets lost. The compressor also employs some schemes		damaged or the synchronization gets lost. The compressor also employs
	through which it ensures the correct transmission of the information		some schemes through which it ensures the correct transmission of the
	to the decompressor.		information to the decompressor.
			2.5 ROHC work in progress
	ROHC for SIP [4] flows use the UDVM (Universal Decompression Virtual		ROHC for SIP [4] flows use the UDVM (Universal Decompression Virtual
	Machine) which accept any encoding code (Deflate, Huffman, Z77, EPIC,		Machine) which accept any encoding code (Deflate, Huffman, Z77, EPIC,
	etc) and use the corresponding byte-code to decompress the packet.		etc). It uses the corresponding byte-code to decompress the packet.
	ROHC for TCP [7] use EPIC (Efficient Protocol Independent Compression)		ROHC for TCP [5] uses an improved compression efficiency method to
	to generate encoding within the ROHC operation modes. EPIC is an		compress TCP header fields including TCP options to generate the
	improvement method of Huffman encoding to reduce a character set.		compressed format packets within the ROHC operation modes.
	The ROHC Negotiation will be done while the tunneling is opened and		3. ROHC Configuration
	it is not the objective of this draft.
	3. ROHC configuration		Each ROHC entity is formed by a compressor and a decompressor, ROHC
			entity will be placed in both MR and HA, each flow will use a ROHC
			context identifier (CID). The profiles used in the tunneling will
			depend on the profiles implemented in each peer negotiated initially.
	ROHC entities formed by a compressor and a decompressor will be		The MNN will not be affected by the use ROHC, and it has to be
	placed in both MR and HA, each flow will use a ROHC context		transparent for the users in the mobile network. The MR will make
	identifier (CID), the use of ROHC will be based on the description		ROHC compression after taking the routing decision and before making
	made in [6] where channels of ROHC are given. The profiles used in		tunneling encapsulation.
	the tunneling will depend on the profiles implemented in each peer
	negotiated initially.
	The ROHC compression parameters need to be studied and are out of the		3.1 Tunneling Encapsulation
	scope of this document. The use of different IP addresses will not be
	a problem as it is explained in section 4. The ROHC classification
	has not change the address will be static all over the life of the
	tunnel.
	The MNN will not be affected by the use of header compression in the		Tunnels between the mobile router and the home agent can be protected
	tunnel, the use of ROHC between the MR and the HA has to be		by ensuring proper use of source addresses, and optional
	transparent for them and for all the users in the mobile network.		cryptographic protection. When protection is requested, Home agent
			and mobile router may use IPsec ESP to protect payload against
			attackers on the path of the tunnel [8,9]. The ROHC packets will be
			encapsulated as shown in figure 2.
	4. Addresses to support NEMO		This document specifies a new protocol value for the IP and IPsec
			next header value to identify ROHC in the tunneling encapsulation.
			Figure 2. Tunneling Encapsulation for ROHC packets.
			+----------------------------+ +----------------------------+
			|IPv6 Header |Nxt. Hdr.= ROHC| |IPv6 Header |Nxt. Hdr.= 50 |
			| +---------------| | +---------------|
			|Src. Addr. : CoA of MR | |Src. Addr. : CoA of MR |
			|Dst. Addr. : HA address | |Dst. Addr. : HA address |
			+----------------------------| +----------------------------|
			|ROHC Packet | |ESP Header |Nxt. Hdr.= ROHC|
			| | | +---------------|
			| | +----------------------------+
			| | |ROHC Packet |
			| | | |
			+----------------------------+ +----------------------------+
			3.2 ROHC packet Format
			Both Negotiation and ROHC Compressed packets will be sent with two
			extra bytes to identify the type of packet and the disorder in the
			link. Figure 3 shows the general format packet of the ROHC packets.
			The Transfer Sequence Number will be used in case of packet
			disordering in the link.
			Figure 3. General Format Packet.
			0 1
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| D | Transfer Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Variable length
			: ROHC Header : (For ROHC format packet see
			: or : section 5.2 of RFC 3095, For
			: Negotiation Header : Negotiation Header see section
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 )
			: :
			: Payload :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			D
			Description Type. Two bits will be used to identify the Negotiation
			ROHC packets from ROHC compressed packets.
			00 Reserved
			01 Negotiation
			10 ROHC Compressed Packets
			11 Reserved
			Transfer Sequence Number
			ROHC was designed to work over an order delivery transmission between
			the compressor and the decompressor. When sending ROHC packets in the
			IP tunneling between the MR and the HA many hops will be crossed by
			different ways, order delivery may not be guaranteed. The Transfer
			Sequence Number will help the decompressor to identify if disordering
			has been produced in the delivery, and before making decompression of
			an early arriving packet, decompressor has to wait until the order
			delivery packet arrived or a timer expires.
			The timer value is out of the scope of this draft, will need to be
			studied depending on the congestion in the network.
			3.3 Negotiation Header Packets
			There is no process of negotiation when packets are sent in a IP
			tunnel. To achieve correct compression, ROHC needs to know some
			parameters in order to be supported by both ends of the tunnel. Based
			on the RFC 3241 [6] which describes the principal parameters to be
			sent in a negotiation for the PPP link, we have created the
			negotiation packets. Compressor will start sending Negotiation
			packets (see Figure 4), when decompressor receives negotiation
			packets it will response with a feedback packet (see figure 5) to
			accept or modified the compressor parameters.
			ROHC Negotiation packets are sent only once, the first time the MR
			leave its home network.
			Figure 4. ROHC Negotiation Packet Format from Compressor to
			Decompressor
			0 1
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| CID Size |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MRRU |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: sub options :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Length
			>= 10
			The length depends on the number of sub options in the negotiation
			packet
			CID Size
			0003 (hex) when small CID is used
			0005 (hex) when large CID is used
			MRRU
			It indicates the maximum reconstructed reception unit, (see RFC 3095,
			section 5.1.1).
			Suggested value = 0
			Sub options
			See RFC 3241 section 2.1, and 2.2 for suboptions description.
			The Profile suboption MUST be supplied.
			Figure 5. ROHC Negotiation Feedback Format from Decompressor to
			Compressor
			0 1 2 3 4 5 6 7
			+-----+-----+-----+-----+-----+-----+-----+-----+
			|Ack. Type | Mode | |
			+-----+-----+-----+-----+ +
			| Transfer Seq. Number |
			+ +-----+-----+-----+-----+-----+-----+
			| : Feedback Options :
			+-----+-----+-----+-----+-----+-----+-----+-----+
			In order to receive the acknowledge or the modification of compressed
			parameters, the Decompressor will used a Feedback type 2 (see RFC
			3095 section 5.7.6
			Ack. Type
			See RFC 3095 section 5.7.6.1
			Mode
			0 = Negotiation Response
			This is a modification made to RFC 3095 will be the identification
			for Negotiation Response. The other values are as RFC 3095 has
			defined.
			Feedback Options
			A new feedback option is introduced, in order to modified the
			negotiation configuration. When the configuration of compressor is
			accepted there is no feedback options.
			0 1 2 3 4 5 6 7
			+---+---+---+---+---+---+
			|Opt. Type = 9 |Option | (See RFC3095 section 5.7.6.2)
			+---+---+---+---+---+---+---+---+
			|Len.= 4|CIDSize|p00|p01|p02|p03| ROHC Profiles
			+---+---+---+---+---+---+---+---+
			|p04|p05|p06|p07|P08| reserved |
			+---+---+---+---+---+---+---+---+
			| |
			+ MRRU +
			| |
			+---+---+---+---+---+---+---+---+
			CID Size
			00 Reserved
			01 Small CID
			10 Large CID
			11 Reserved
			Profiles
			Each bit represent a supported profile, when the bit is 1 the
			profile is supported when it is 0 the profile is not supported.
			The p-value represents the Profile of ROHC. When any profile is
			matching at both sizes profile 0 is used.
			p00 Profile 0. Without Compression
			p01 Profile 1. IP/UDP/RTP
			p02 Profile 2. IP/UDP
			p03 Profile 3. IP/ESP
			p04 Profile 4. IP
			p05 Profile 5. LLA for U/O-mode
			p06 Profile 6. LLA for R mode
			p07 Profile 7. IP/UDP-Lite/RTP
			p08 Profile 8. IP/UDP-Lite
			MRRU
			The maximum reconstructed unit supported by decompressor.
			3.4 ROHC Parameter Values
			A number of ROHC parameters must be set correctly for good
			compression over the IP tunnel. The compression approach, the timers
			of unidirectional mode, the k1, n1, k2, n2 and the timer for
			disordering waiting has to be studied and are out of scope of this
			document.
			3.5 ROHC Profiles
			All the other ROHC profiles can be used, it depends on the
			MNN traffic and the profile supported by MR and HA ROHC
			compressor/decompressor.
			4. Modifications to NEMO Basic Support
			4.1 Home Agent Operation
			When HA intercepts packets which are destined to mobile router, HA
			should be able to apply ROHC header compression to packets just after
			the routing decision and before the IP encapsulation.
			HA should be able to execute ROHC compressor and decompressor.
			4.2 Mobile Router Operation
			When packets are issued by the mobile network, MR should be able to
			apply ROHC header compression to packets just after the routing
			decision and before the IP encapsulation.
			MR should be able to execute ROHC compressor and decompressor.
			4.3 Use of Addresses
	To support NEMO, MR uses two types of addresses: the home addresses		To support NEMO, MR uses two types of addresses: the home addresses
	which are static and they are used when MR is at its home networking		which are static and they are used when MR is at its home networking
	and the care-of addresses which are dynamic and they change with the		and the care-of addresses which are dynamic and they change with the
	attachment point. The HA will keep a binding cache for MR.		attachment point. The HA will keep a binding cache for MR.
			While MR is in its home networking header compression will not be
			used.
	4.1 Addresses for header compression		The addresses used for ROHC will be the MNN (Mobile Network Node) as
			source address and the CN (Corresponding Node) as destination
	ROHC mechanisms classifies the header fields to make compression.		address. The Address will not change while the MN moves around.
	This analysis is based on how the values in the header fields change
	during a stream. These fields are separated and assigned to the
	static and the dynamic chain of the compressed header packets.
	The MR will acquire a care-of address (CoA) from its attachment		IANA Considerations
	point and it will use it to make header compression. While MR is in
	its home networking header compression will not be used.
	As the addresses are classified as static, each time the MR changes		This document defines a new IPv6 protocol and IPsec protocol, the
	its attachment point the ROHC context will be initialized.		ROHC Next Header, described in Section 3.1.
	Security Considerations		Security Considerations
	This document by it self does not add any security risk to the use		This document by it self does not add any security risk to the use of
	of ROHC and NEMO as they have already been defined.		ROHC and NEMO as they have already been defined in [2] and [7].
	References		References
	1 Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,		1 Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
	February 2004.		February 2004.
	2 Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu,		2 Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
	H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z.,		Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
	Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura,		Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
	T. and H. Zheng, "RObust Header Compression (ROHC): Framework and		Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC):
	four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,		Framework and four profiles: RTP, UDP, ESP, and uncompressed",
	July 2001.		RFC 3095, July 2001.
	3 Jonsson, L-E., Pelletier, G., "RObust Header Compression (ROHC):		3 Jonsson, L-E., Pelletier, G., "RObust Header Compression (ROHC):
	A Compression Profile for IP", RFC 3843, June 2004.		A Compression Profile for IP", RFC 3843, June 2004.
	4 Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.,		4 Pelletier, G., "RObust Header Compression (ROHC): Profiles for
	Rosenberg, J., "Signaling Compression (SigComp)", RFC 3320,		User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
	January 2003.
	5 Jonsson, L-E., Pelletier, G., "Robust Header Compression (ROHC):		5 Pelletier, G., Jonsson, L-E., West, M., Price, R., Sandlund, K.,
	A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242,		"Robust Header Compression (ROHC): A Profile for TCP/IP
	April 2002.		(ROHC-TCP)", <draft-ietf-rohc-tcp-08.txt>, October 2004.
	6 Liu, Z., Le, K., "Zero-byte for Bidirectional Reliable Mode		6 Bormann, C., "RObust Header Compression (ROHC) over PPP", RFC
	(R-mode) in Extended Link-layer Assisted Robust Header Compression		3241, April 2002.
	(ROHC) Profile", RFC 3408, December 2002.
	7 Pelletier, G., Jonsson, L-E., West, M., Price, R., Sandlund, K.,		7 Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P.,"Network
	"Robust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)",		Mobility (NEMO) Basic Support Protocol", rfc3963, 2005.
	<draft-ietf-rohc-tcp-08.txt>, October 2004.
	8 Pelletier, G., "RObust Header Compression (ROHC): Profiles for		8 Johnson, D., Perkins, C., Arkko, J., "Mobility Support In IPv6",
	UDP-Lite", <draft-ietf-rohc-udp-lite-04.txt>, June 2004.		RFC 3775, 2004.
	9 Devarapalli, V., Wakikawa, R., Petrescu, A., Thubert, P., "Network		9 Arkko, J., Devarapalli, V., Dupont, F.,"Using IPSec to Protect
	Mobility (NEMO) Basic Support Protocol", rfc3963, 2005.		Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
			RFC3776, 2004.
	Author's Addresses		Author's Addresses
	Ana Minaburo		Ana Minaburo
	ENST-Bretagne		ENST-Bretagne
	2 rue de la Chataigneraie ¡ CS 17607		2 rue de la Chataigneraie - CS 17607
	35576 Cesson Sevigne Cedex		35576 Cesson Sevigne Cedex
	Phone: (+33) 299 127054		Phone: (+33) 299 127054
	Email: anacarolina.minaburo@enst-bretagne.fr		Email: anacarolina.minaburo@enst-bretagne.fr
	Eun Kyoung Paik		Eun Kyoung Paik
	KT		KT
	Portable Internet Team, Convergence Lab., KT		Portable Internet Team, Convergence Lab., KT
	17 Woomyeon-dong, Seocho-gu		17 Woomyeon-dong, Seocho-gu
	Seoul 137-792		Seoul 137-792
	Korea		Korea
	Phone: +82-2-526-5233		Phone: +82-2-526-5233
	Fax: +82-2-526-5200		Fax: +82-2-526-5200
	Email: euna@kt.co.kr		Email: euna@kt.co.kr
	URI: http://mmlab.snu.ac.kr/~eun/		URI: http://mmlab.snu.ac.kr/~eun/
	Laurent Toutain		Laurent Toutain
	ENST-Bretagne		ENST-Bretagne
	2 rue de la Chataigneraie - CS 17607		2 rue de la Chataigneraie - CS 17607
	35576 Cesson Sevigne Cedex		35576 Cesson Sevigne Cedex
	Phone: (+33) 299 127026		Phone: (+33) 299 127026
	Email: laurent.toutain@enst-bretagne.fr		Email: laurent.toutain@enst-bretagne.fr
	URI: http://www.rennes.enst-bretagne.fr/~toutain/		URI: http://www.rennes.enst-bretagne.fr/~toutain/
			Jean-Marie Bonnin
			ENST-Bretagne
			2 rue de la Chataigneraie - CS 17607
			35576 Cesson Sevigne Cedex
			Phone: (+33) 299 127026
			Email: jm.bonnin@enst-bretagne.fr
			Change Log
			Changes from draft-minaburo-rohc-nemo-00 to 01:
			* Restructuring of Section 2:
			+ Divide in sections the ROHC description.
			* Restructuring of Section 3:
			+ Added section 3.1 Tunneling Encapsulation
			+ Added section 3.2 ROHC Packet Format
			+ Added section 3.3 Negotiation Header Format
			+ Moved part of section 3 to section 3.4 ROHC parameters
			+ Added ROHC Profiles
			* Restructuring of Section 4:
			+ Re-named section title 'NEMO addresses' to 'Modifications to NEMO Basic Support '
			+ Added section 4.1 Home Agent Operation
			+ Added section 4.2 Mobile Router Operation
			+ Moved section '4.1 Addresses for header compression' to section '4.3 Use of Addresses'
	Copyright Statement		Copyright Statement
	"Copyright (C) The Internet Society (2005). This document is subject		"Copyright (C) The Internet Society (2005). 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."
	"This document and the information contained herein are provided on		"This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
End of changes. 42 change blocks.
	152 lines changed or deleted		462 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/