Network Working Group W. Imajuku, Ed.
Internet-Draft NTT Com
Intended status: Informational T. Otani, Ed.
Expires: December 14, 2009 KDDI
N. Bitar, Ed.
Verizon
June 12, 2009
Service Provider Requirements for Ethernet control with GMPLS
draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
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 December 14, 2009.
Imajuku, et al. Expires December 14, 2009 [Page 1]
Internet-Draft Service Provider Requirements June 2009
Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
Ethernet switches supporting Provider Backbone Bridge Traffic
Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label
switch network not only automates creation of Ethernet Label Switched
Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
Mechanisms such as protection and restoration of an Eth-LSP. This
document describes the requirements for the set of solutions of GMPLS
controlled Ethernet label switch networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Single Layer . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Multi Layer . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Control plane architecture and functionality . . . . . . . 7
4.1.1. In-band control channel . . . . . . . . . . . . . . . 7
4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7
4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7
4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7
4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7
4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8
4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8
4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8
4.3. OA&M related functionality . . . . . . . . . . . . . . . . 9
4.4. Protection and Restoration related functionality . . . . . 9
4.5. Link Aggregation Group (LAG) related functionality . . . . 9
4.5.1. Failure or deletion of LAG member link . . . . . . . . 9
4.5.2. Recovery or addition of LAG member link . . . . . . . 9
4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9
4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10
4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10
4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10
4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Imajuku, et al. Expires December 14, 2009 [Page 2]
Internet-Draft Service Provider Requirements June 2009
1. Introduction
Scalability and manageability of Ethernet switch networks has
continuously improved, and the deployment of Ethernet switches
supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the
solutions for service providers to provide enterprise WAN/LAN
services. IEEE standardization activities of Provider Backbone
Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE)
[IEEE802.1Qay] provide an opportunity not only for enhancing the
scalability, manageability, and controllability of the Ethernet
service networks, but also for more efficiently deploying access/
metro access networks.
Generalized Multi-Protocol Label Switching (GMPLS) provides the
framework for handling and controlling various types of connection-
oriented switching technologies, namely packet switching with various
label formats TDM switching, and wavelength switching [RFC3945].
Therefore, the combined use of GMPLS and PBB-TE is a fairly suitable
"use case" that contributes to enhancing the flexibility of Ethernet
Label Switched Path (Eth-LSP) over Ethernet switch networks without
defining additional connection layers.
This document describes requirements for GMPLS protocols to control
Ethernet label switch networks and comprises mainly two parts. The
first one is the requirements for GMPLS extension for controlling
Ethernet layer. The second one includes the requirements for GMPLS
extensions to support multi-layer operation. Although a large
portion of requirements in the second scope coincides with the
description in [RFC5145] and [RFC5146], some of important
requirements are also described in this document.
Imajuku, et al. Expires December 14, 2009 [Page 3]
Internet-Draft Service Provider Requirements June 2009
2. Conventions used in this document
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 [RFC2119].
Imajuku, et al. Expires December 14, 2009 [Page 4]
Internet-Draft Service Provider Requirements June 2009
3. Reference model
3.1. Single Layer
This document describes requirements based on the reference model
depicted in Fig.1. The first reference model is an intra-domain and
single layer GMPLS controlled Ethernet label switching network in
which Eth-LSPs traverse over between Backbone Core Bridges (BCBs) or
Backbone Edge Bridges (BEBs).
-------- ----- --------
P-based IF --| LSR1 |____|LSR2 |_____| LSR3 |-- P-based IF
S-tagged IF --|(IB-BEB)| |(BCB)| |(IB-BEB)|-- S-tagged IF
I-tagged IF --| | | | | |-- I-tagged IF
-------- ----- --------
| GMPLS Eth-LSP |
| (BVID/BMAC) |
|<-------------->|
Figure 1 Single layer GMPLS controlled PBB-TE network
The BEBs provide mainly three types of service interfaces, namely
Port based service interface (P-based IF), S-tagged service interface
(S-tagged IF), and I-tagged service Interface (I-tagged IF)
[IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to
the I-component of a BEB (I-BEB), while the I-tagged IF is connected
to the B-component of a BEB (B-BEB). "S-tagged IF" can perform
various types of mapping between Service VLAN ID (S-VID) and Backbone
instance Service Identifier (I-SID). Here, S-VID is assigned within
customer network domain or Provider Bridge (PB) domain. On the other
hand, I-SID is defined between I-components of BEBs.
3.2. Multi Layer
The second reference model is Ethernet and L1 (such as TDM, OTN, etc)
multi-layer network. Each Ethernet switch node behaves as a border
node between the Ethernet layer and optical Layers. Each BCB or BEB
terminates Optical Label Switched Path (O-LSPs) with Ethernet
encoding type and some O-LSPs dynamically form LAG. Thus, some Eth-
LSPs traverse over multiple O-LSPs, while other Eth-LSPs traverse
over single O-LSPs.
Also, it is technically possible to form multiple layer Ethernet
switch networks. Namely, the reference model is defined as the case
that Ethernet switch network substitutes L1 network in Fig.2, and
realizes MAC in MAC Ethernet transport. The routing information of
optical layer may be isolated (overlay model), shuffled (peer model),
Imajuku, et al. Expires December 14, 2009 [Page 5]
Internet-Draft Service Provider Requirements June 2009
or virtualized with FA-LSPs (augmented model) for Ethernet switch
layer.
-------- ------ --------
P-based IF --| LSR1 | | LSR2 | | LSR3 |-- P-based IF
S-tagged IF --|(IB-BEB)| | (BCB)| |(IB-BEB)|-- S-tagged IF
I-tagged IF --| | | | | |-- I-tagged IF
-------- ------ --------
| | ||LAG LAG||
..................|...........|..||..........||...................
| | || ||
---+---- ------ ------
| LSR A |_____|LSR B |_____|LSR C |
| (LSC) | |(LSC) | WDM |(LSC) |
-------- ------ ------
| GMPLS Eth-LSP (BVID/BMAC)|
|<------------------------>|
| O-LSP | | O-LSP |
|<--------->| |<-------->|
Figure 2 Multi-layer GMPLS controlled Ethernet label switched network
Imajuku, et al. Expires December 14, 2009 [Page 6]
Internet-Draft Service Provider Requirements June 2009
4. Requirements
Section 4.1 to 4.6 describe requirements for single layer Ethernet
label swicth network based on the reference model from Fig.1. In
addition, section 4.7 describes requirements for multiple layer
network with Ethernet layer and circuit switch layer (such as
wavelength switched layer and so on). Finally, section 4.8 describes
generic requirements applicable to single and multiple layer
networks.
4.1. Control plane architecture and functionality
4.1.1. In-band control channel
The solution should be able to establish in-band control channel,
while preserving the solution of out-band control channel. The
solution should include negotiation mechanism to specify bandwidth
and priority of control-channel between peer Ethernet switches.
4.1.2. Neighbor discovery mechanism
The solution MUST be able to realize automatic neighbor discovery as
realized in current PB or PBB networks. Namely, the solution MUST
support an automatic negotiation mechanism to exchange information of
Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and
IP address of the control channel for these configuration between
neighbors. On the other hand, the extension should be minimized by
making use of [RFC4394] and [IEEE802.1AB].
4.1.3. Addressing
All service interfaces, TE-Link IDs and Data-link IDs MUST be able to
be indicated by standard IEEE MAC address format, but Node ID should
be with IP addresses.
4.2. Ethernet LSP control
4.2.1. Prevention of Loops
The solution should have reliability to prevent creating loops of
Eth-LSPs. Specifically if the solution supports numbered TE-Link
addressing, the solution should define a methodology and protocol
extensions if needed to detect or prevent loops.
4.2.2. Service control
The solution should control various types of service interfaces
defined in [IEEE802.1ah]. The service types of Egress port
Imajuku, et al. Expires December 14, 2009 [Page 7]
Internet-Draft Service Provider Requirements June 2009
1) Port based service interface
2) S-tagged service interface
a) one-to-one mapping of S-VIDs to I-SIDs
b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to-
one, transparent mapping
3) I-tagged service interface should be controllable in addition to
assignment of Egress port itself.
Also, the solution should be flexible to following operational
scenarios,
1) Any change of mapping of S-VIDs to I-SIDs
2) Flexibility to nest or stitch higher layer Eth-LSPs.
3) Any change of bandwidth of Eth-LSPs. Here, the solution of
bandwidth modification scenario may include bundling of multiple Eth-
LSPs.
4.2.3. P2MP and MP2MP requirements
To provide the service such as a content distribution, the creation
of uni-directional P2MP Eth-LSPs should be supported. Also, to
provide E-tree type services with multicast traffic, the creation of
bi-directional P2MP Eth-LSPs should be supported. The MP2MP
requirement is for further study.
4.2.4. Asymmetric bandwidth
To provide the service which has asymmetric traffic pattern such as a
kind of E-tree type services, the creation of asymmetric bandwidth
bi-directional Eth-LSPs should be supported. The bandwidth
modification of Eth-LSPs in operation should be also supported.
4.2.5. QoS control
The routing and signaling extensions to control QoS based on Ethernet
traffic parameters defined in [MEF10.1] should be supported. Unused
bandwidth per CoS should be exhanged by routing extensions like
[RFC4124] and the CoS and bandwidth profile such as CIR, CBS, EIR and
EBS for a requested LSP should be carried by signaling extensions for
bandwidth accounting and traffic control at a local level.
Imajuku, et al. Expires December 14, 2009 [Page 8]
Internet-Draft Service Provider Requirements June 2009
4.3. OA&M related functionality
OAM mechanisms must be defined for GMPLS controlled E-LSPs. Since
the data plane is still Ethernet based, the mechanisms should
capitalize on existing [IEEE802.1ag] and [Y.1731] mechanisms.
Also, the solution should provide admin status control mechanism to
coordinate with Connectivity Fault Management (CFM) functionality
[IEEE802.1ag].
4.4. Protection and Restoration related functionality
1:1 protection, Shared protection and dynamic restoration should be
supported. Protection and Restoration may be triggered by Ethernet
OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731].
4.5. Link Aggregation Group (LAG) related functionality
Link Aggregation is beneficial functionality to realize flexible
reconfiguration of logical link bandwidth and reliable Ethernet label
switched networks. The availability of link bandwidth between peer
Ethernet switches can be enhanced.
The solution should support Link Bundling mechanism described in
[RFC4201] to explicitly assign the links forming LAG.
4.5.1. Failure or deletion of LAG member link
The solution should include functionality to prioritize Eth-LSPs,
specifically when total bandwidth of Eth-LSPs exceeds total bandwidth
of healthy LAG members after the failure of one or more LAG member
links.
The solution should provide for rerouting an Eth-LSP setup over a
failed member link in a LAG to another member link in the LAG.
4.5.2. Recovery or addition of LAG member link
The solution should include functionality to re-optimize Eth-LSP
paths after the addition of a LAG member link, i.e. reversion of
failed Eth-LSPs after the failure of the LAG member link, or
reallocation of other Eth-LSPs traversing congested Links after the
addition of LAG member link.
4.6. Inter-domain Ethernet LSP
The solution should take into account possible future extension to
control inter-domain Eth-LSPs. Here, the possible extensions are
Imajuku, et al. Expires December 14, 2009 [Page 9]
Internet-Draft Service Provider Requirements June 2009
Eth-LSPs traverse over
1) I-tagged service interfaces
2) S-tagged service interfaces, and
3) C-tagged service interfaces.
4.7. Multi-layer network
4.7.1. Dynamic formation of LAG
The solution should include dynamic formation of a LAG after the
creation or deletion of optical LSPs which interconnect ports of
Ethernet switches. It should use the existing Link Bundling
mechanism to assign bandwidth to dynamically formulated LAG.
4.7.2. Other requirements
The architecture and requirements for MPLS-GMPLS inter-working are
described in [RFC5145] and [RFC5146]. Some of the requirements
described in [RFC5146] are valid even for the case of GMPLS-GMPLS
interworking between Ethernet label switched network and L1 network.
In other words,
1) End-to-End signaling of Eth-LSPs
2) Triggered establishment of L1 LSPs
3) Avoiding complexity and risks.
should be satisfied even for GMPLS control plane for Ethernet. For
more details, see [RFC5146] and MPLS-TE client network written in the
document should be understood as Ethernet client network.
Regarding to routing issue,
1) Advertisement of Ethernet label switch network information via L1
GMPLS networks
2) Selective Advertisement of Ethernet label switched network
information via a Border node
should be satisfied even in the case of GMPLS-GMPLS inter-working.
Note that there is significant difference between MPLS-TE and GMPLS
controlled Ethernet from the view point of methodology to create
control channel.
Imajuku, et al. Expires December 14, 2009 [Page 10]
Internet-Draft Service Provider Requirements June 2009
4.8. Scalability
The solution MUST be designed to scale according to following
metrics.
- Number of nodes
- Number of TE-Links
- Number of LSPs
- Number of service ports
- Number of bundled S-VLANs mapped to I-SID and Eth-LSPs
- Number of advertised VLANs
- Number of MEPs and MIPs.
Imajuku, et al. Expires December 14, 2009 [Page 11]
Internet-Draft Service Provider Requirements June 2009
5. Security Considerations
The extension for GMPLS controlled Ethernet label switching should be
considered under the same security as current work. This extension
will not change the underlying security issues.
Imajuku, et al. Expires December 14, 2009 [Page 12]
Internet-Draft Service Provider Requirements June 2009
6. IANA Considerations
This document has no actions for IANA.
Imajuku, et al. Expires December 14, 2009 [Page 13]
Internet-Draft Service Provider Requirements June 2009
7. Acknowledgements
The authors would like to thank Mr. Allan McGuire, Mr. Jullien
Meuric, Mr. Lou Berger, Mr. Don Fedyk and Mr. Attila Takacs for their
valuable comments.
Imajuku, et al. Expires December 14, 2009 [Page 14]
Internet-Draft Service Provider Requirements June 2009
8. References
8.1. Normative References
[IEEE802.1AB]
"IEEE Standard for Local and Metropolitan Area Networks,
Station and Media Access Control Connectivity Discovery".
[IEEE802.1Qay]
"IEEE standard for Provider Backbone Bridges Traffic
Engineering", work in progress.".
[IEEE802.1ad]
"IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,
Draft, Work in Progress".
[IEEE802.1ag]
"IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 5 : Connectivity Fault Management",
P802.1ag/D5.2, Draft, Work in Progress".
[IEEE802.1ah]
"IEEE standard for Provider Backbone Bridges", work in
progress.".
[IEEE802.3]
"IEEE Computer Society, "Amendment to Carrier Sense
Multiple Access with Collision Detection (CAMS/CD) Access
Method and Physical Layer Specifications".
[MEF10.1] "MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http
://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf,
Nov. 2006.".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[Y.1731] "ITU-T Y.1731".
Imajuku, et al. Expires December 14, 2009 [Page 15]
Internet-Draft Service Provider Requirements June 2009
8.2. Informative References
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D.
Papadimitriou, "A Transport Network View of the Link
Management Protocol (LMP)", RFC 4394, February 2006.
[RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration",
RFC 5145, March 2008.
[RFC5146] Kumaki, K., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
March 2008.
Imajuku, et al. Expires December 14, 2009 [Page 16]
Internet-Draft Service Provider Requirements June 2009
Authors' Addresses
Wataru Imajuku (editor)
NTT Communications Corporation
1-1-6 Uchisaiwai-cho
Chiyoda-ku, Tokyo
Japan
Phone: +81-(46) 859-4315
Email: imajuku.wataru@lab.ntt.co.jp
Yoshiaki Sone
NTT Network Innovation Labs
1-1 Hikari-no-oka
Yokosuka, Kanagawa
Japan
Phone: +81-(46) 859-2456
Email: sone.yoshiaki@lab.ntt.co.jp
Muneyoshi Suzuki
NTT Access Service System Labs
1-6 Nakase
Mihama-ku, Chiba
Japan
Phone: (43) 211-8282
Email: suzuki.muneyoshi@lab.ntt.co.jp
Kazuhiro Matsuda
NTT Network Innovation Labs
1-1 Hikari-no-oka
Yokosuka, Kanagawa
Japan
Phone: (46) 859-3177
Email: matsuda.kazuhiro@lab.ntt.co.jp
Imajuku, et al. Expires December 14, 2009 [Page 17]
Internet-Draft Service Provider Requirements June 2009
Tomohiro Otani (editor)
KDDI Corporation
2-3-2 Nishi-shinjuku
Shinjuku-ku, Tokyo 163-8003
Japan
Phone: +81-(3) 3347-6006
Email: tm-otani@kddi.com
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara
Kamifukuoka, Saitama 356-8502
Japan
Phone: +81-(49) 278-7897
Email: ogaki@kddilabs.jp
Nabil Bitar (editor)
Verizon
40 Sylvan Road
Waltham, MA 02451
USA
Email: nabil.n.bitar@verizon.com
Imajuku, et al. Expires December 14, 2009 [Page 18]
Internet-Draft Service Provider Requirements June 2009
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
Imajuku, et al. Expires December 14, 2009 [Page 19]
Internet-Draft Service Provider Requirements June 2009
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Imajuku, et al. Expires December 14, 2009 [Page 20]
