One document matched: draft-zheng-dhc-relay-agent-stacking-00.txt
Dynamic Host Configuration WG R. Zheng
Internet-Draft H. Li
Intended status: Standards Track Z. Zhang
Expires: April 22, 2010 Huawei Technologies
October 19, 2009
DHCP Relay Agent Stacking
draft-zheng-dhc-relay-agent-stacking-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zheng, et al. Expires April 22, 2010 [Page 1]
Internet-Draft Option 82 stacking October 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
According to RFC 3046, there is only one DHCP Option 82 allowed in a
certain DHCP message. This document describes several cases that
need more than one Relay Agent to add link information. Proposed
method is to have different Relay Agents add multiple DHCP Option 82.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Zheng, et al. Expires April 22, 2010 [Page 2]
Internet-Draft Option 82 stacking October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Multi-level Access Loop Identification Scenarios . . . . . . . 4
3. Stacking DHCP Option 82 Syntax . . . . . . . . . . . . . . . . 5
4. Agent Operation . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zheng, et al. Expires April 22, 2010 [Page 3]
Internet-Draft Option 82 stacking October 2009
1. Introduction
In a typical DSL access network, DHCP Relay Agent Option is used to
carry the access loop identification, which identifies the access
loop of the user and is useful for troubleshooting and policy
management functions. In FTTC/FTTB scenarios of PON system, there
are multiple subscribers behind an ONU and both OLT and ONU's slot/
port information are needed to identify a use accurately. However, a
DHCP Relay Agent does NOT add a "second" relay agent option, when it
receives a DHCP packet with a Relay Agent Information option already
present from a trusted circuit, according to chapter 2.1 of
[RFC3046].
As described in[draft-huang-dhc-relay-ps-00], when a layer 3 switch
is installed for a 20 floor building and a layer 2 switch is
installed at each floor inside this building, there is a policy
delivery problem if only one relay agent inserts access loop
identification.
If we define a new sub-option, DHCP Relay Agents appending access
loop identification to existing DHCP Option 82 will have to identify
the information inserted by other Relay Agents previously, which is
complicated. Another reason not to do so, is that some options can't
be changed because of the signature. Define a new option x is also a
bad choice because of incompatibility with legacy device.
What is proposed is to insert multiple DHCP Option 82 to a DHCP
packet. Stacking DHCP Option 82 is much simpler and is able to void
the problems mentioned above.
2. Multi-level Access Loop Identification Scenarios
There are at least two cases where multi-level access loop
identification is needed to be carried in DHCP packets.
A typical PON FTTB/FTTC network includes OLT, ONU and ODN, as
depicted in figure 1. ONU can be Multi-Dwelling Unit (MDU) or Multi-
Tenant Unit (MTU). In this case, ONU provides network access for
multiple residential users or multiple business users via DSL or
Ethernet typically. In order to locate a user precisely from a DHCP
message via Option 82, ONU need add a user's access loop
identification on which port the user is attached, while OLT need add
PON port where the ONU is attached. Therefore, two DHCP Relay Agents
reside in ONU and OLT respectively.
Zheng, et al. Expires April 22, 2010 [Page 4]
Internet-Draft Option 82 stacking October 2009
+---------+
|AAA |
|server | /---\ +-------+
+---------+ /-/ \\ | |----User
\ | | / | MDU |
+------+ \ +-------+ +-----+ / | |----User
|BRAS |Layer 2\ |OLT | |ODN |/ +-------+
|/BNG |network----| |----| |\
+------+ | +-------+ +-----+ \ +-------+
| | | \ | |----User
+--------+ / \\ | \| MTU |
|DHCP |/ \-------/ | |----User
|server | +-------+
+--------+
Figure 1: FTTB/FTTC network with PON
Another case is cascaded LAN system, which port information of multi-
level LAN switches is needed to locate a user. There is more
information of this case in[draft-huang-dhc-relay-ps-00]. Figure 2
depicts an example of this case. Both curb switch and floor switch
need add access loop identifier to DHCP Option 82. That means there
are two levels of DHCP Relay Agents.
/--------\
/-/ \\
| \\ +--------+ +--------+
+------+ | \\ | | | |----User
|DHCP |----| Aggregation \\----|curb |----|floor |
|server| | network | |switch | |switch |
+------+ | // | | | |----User
\\ /-/ +--------+ +--------+
\-\ //
\-------/
Figure 2: Cascaded LAN access system
3. Stacking DHCP Option 82 Syntax
There is no change to the syntax specified in [RFC3046](DHCP Relay
Agent Information Option) in a Type-Length-Value format.
4. Agent Operation
A trusted circuit of a DHCP Relay Agent is attached by a trusted
Zheng, et al. Expires April 22, 2010 [Page 5]
Internet-Draft Option 82 stacking October 2009
downstream (closer to client) network element, which is between the
current DHCP Relay Agent and the client. The current DHCP Relay
Agent MAY add a DHCP relay agent option but not set the giaddr field.
In the case of multi-level DHCP Relay Agent, the current DHCP Relay
Agent can add a "second" relay agent option to a DHCP packet that has
a DHCP relay agent option which was added by a trusted DHCP Relay
Agent attached to the trusted circuit. The DHCP packet will further
be forwarded per normal DHCP relay agent operations, setting the
giaddr field as it deems appropriate.
A DHCP relay agent adding a Relay Agent Information field SHALL
always add it as the last option (but before 'End Option' 255, if
present) in the DHCP options field of any recognized BOOTP or DHCP
packet. When there are multiple DHCP Option 82 in a packet, the
options should be arranged in the order of time sequence.
The Relay Agent Information option echoed by a server MUST be removed
by either the relay agent or the trusted downstream network element
which added it when forwarding a server-to-client response back to
the client. If there are multiple DHCP Option 82 in a DHCP packet,
Option 82 added previously will become the last option (but before
'End Option' 255, if present) in the DHCP options field after last
option82 is striped.
5. Applicability
Option 82 stacking is practicable in the scenario of multiple Relay
Agents between DHCP client and DHCP server. Multiple Relay Agents
are especially common in FTTB/FTTC with PON or multi-level switches
based access network.
6. Security Considerations
This document has no security effect on current mechanism in
addressing security attacks.
7. IANA Consideration
No requests to IANA.
8. Informative References
[RFC2119] "", <http://tools.ietf.org/rfc/rfc2119.txt>.
Zheng, et al. Expires April 22, 2010 [Page 6]
Internet-Draft Option 82 stacking October 2009
[RFC3046] IETF, "DHCP Relay Agent Information Option", January 2001,
<http://tools.ietf.org/rfc/rfc3046.txt>.
[draft-huang-dhc-relay-ps-00]
IETF, "Line identification in IPv6 Router Solicitation
messages", July 2009, <http://tools.ietf.org/id/
draft-krishnan-6man-rs-mark-03.txt>.
Authors' Addresses
Ruobin Zheng
Huawei Technologies
Shenzhen,
China
Phone: +86-755-28972352
Email: robin@huawei.com
URI:
Hongyu Li
Huawei Technologies
Shenzhen,
China
Phone: +86-755-28973567
Fax:
Email: lihy@huawei.com
URI:
Zhongjian Zhang
Huawei Technologies
Shenzhen,
China
Phone: +86-755-28978503
Fax:
Email: zhangzhongjian@huawei.com
URI:
Zheng, et al. Expires April 22, 2010 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 15:13:37 |