BCP 47 Extension T - Transformed Content
RFC 6497
| Document | Type |
RFC
- Informational
(February 2012)
Errata
Was
draft-davis-t-langtag-ext
(individual in app area)
|
|
|---|---|---|---|
| Authors | Mark Davis , Courtney Falk , Addison Phillips , Yoshito Umaoka | ||
| Last updated | 2022-10-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | Pete Resnick | |
| Send notices to | (None) |
RFC 6497
Internet Engineering Task Force (IETF) M. Davis
Request for Comments: 6497 Google
Category: Informational A. Phillips
ISSN: 2070-1721 Lab126
Y. Umaoka
IBM
C. Falk
Infinite Automata
February 2012
BCP 47 Extension T - Transformed Content
Abstract
This document specifies an Extension to BCP 47 that provides subtags
for specifying the source language or script of transformed content,
including content that has been transliterated, transcribed, or
translated, or in some other way influenced by the source. It also
provides for additional information used for identification.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6497.
Davis, et al. Informational [Page 1]
RFC 6497 BCP 47 Extension T February 2012
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. BCP 47 Required Information .....................................4
2.1. Overview ...................................................4
2.2. Structure ..................................................6
2.3. Canonicalization ...........................................7
2.4. BCP 47 Registration Form ...................................8
2.5. Field Definitions ..........................................8
2.6. Registration of Field Subtags .............................10
2.7. Registration of Additional Fields .........................11
2.8. Committee Responses to Registration Proposals .............11
2.9. Machine-Readable Data .....................................11
3. Acknowledgements ...............................................14
4. IANA Considerations ............................................14
5. Security Considerations ........................................14
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................15
1. Introduction
[BCP47] permits the definition and registration of language tag
extensions "that contain a language component and are compatible with
applications that understand language tags". This document defines
an extension for specifying the source of content that has been
transformed, including text that has been transliterated,
transcribed, or translated, or in some other way influenced by the
source. It may be used in queries to request content that has been
transformed. The "singleton" identifier for this extension is 't'.
Davis, et al. Informational [Page 2]
RFC 6497 BCP 47 Extension T February 2012
Language tags, as defined by [BCP47], are useful for identifying the
language of content. There are mechanisms for specifying variant
subtags for special purposes. However, these variants are
insufficient for specifying content that has undergone
transformations, including content that has been transliterated,
transcribed, or translated. The correct interpretation of the
content may depend upon knowledge of the conventions used for the
transformation.
Suppose that Italian or Russian cities on a map are transcribed for
Japanese users. Each name needs to be transliterated into katakana
using rules appropriate for the specific source and target language.
When tagging such data, it is important to be able to indicate not
only the resulting content language ("ja" in this case), but also the
source language.
Transforms such as transliterations may vary, depending not only on
the basis of the source and target script, but also on the source and
target language. Thus, the Russian <U+041F U+0443 U+0442 U+0438
U+043D> (which corresponds to the Cyrillic <PE, U, TE, I, EN>)
transliterates into "Putin" in English but "Poutine" in French. The
identifier could be used to indicate a desired mechanical
transformation in an API, or could be used to tag data that has been
converted (mechanically or by hand) according to a transliteration
method.
In addition, many different conventions have arisen for how to
transform text, even between the same languages and scripts. For
example, "Gaddafi" is commonly transliterated from Arabic to English
as any of (G/Q/K/Kh)a(d/dh/dd/dhdh/th/zz)af(i/y). Some examples of
standardized conventions used for transcribing or transliterating
text include:
a. United Nations Group of Experts on Geographical Names (UNGEGN)
b. US Library of Congress (LOC)
c. US Board on Geographic Names (BGN)
d. Korean Ministry of Culture, Sports and Tourism (MCST)
e. International Organization for Standardization (ISO)
The usage of this extension is not limited to formal transformations,
and may include other instances where the content is in some other
way influenced by the source. For example, this extension could be
used to designate a request for a speech recognizer that is tailored
Davis, et al. Informational [Page 3]
RFC 6497 BCP 47 Extension T February 2012
specifically for second-language speakers who are first-language
speakers of a particular language (e.g., a recognizer for "English
spoken with a Chinese accent").
1.1. 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].
2. BCP 47 Required Information
2.1. Overview
Identification of transformed content can be done using the 't'
extension defined in this document. This extension is formed by the
't' singleton followed by a sequence of subtags that would form a
language tag as defined by [BCP47]. This allows the source language
or script to be specified to the degree of precision required. There
are restrictions on the sequence of subtags. They MUST form a
regular, valid, canonical language tag, and MUST neither include
extensions nor private use sequences introduced by the singleton 'x'.
Where only the script is relevant (such as identifying a script-
script transliteration), then 'und' is used for the primary language
subtag.
For example:
+---------------------+---------------------------------------------+
| Language Tag | Description |
+---------------------+---------------------------------------------+
| ja-t-it | The content is Japanese, transformed from |
| | Italian. |
| ja-Kana-t-it | The content is Japanese Katakana, |
| | transformed from Italian. |
| und-Latn-t-und-cyrl | The content is in the Latin script, |
| | transformed from the Cyrillic script. |
+---------------------+---------------------------------------------+
Note that the sequence of subtags governed by 't' cannot contain a
singleton (a single-character subtag), because that would start a new
extension. For example, the tag "ja-t-i-ami" does not indicate that
the source is in "i-ami", because "i-ami" is not a regular language
tag in [BCP47]. That tag would express an empty 't' extension
followed by an 'i' extension.
Davis, et al. Informational [Page 4]
RFC 6497 BCP 47 Extension T February 2012
The > /l2vpn-svc/vpn-services/
| | vpn-service/vpn-id
| +--rw site-role? identityref
+--rw service
| +--rw qos {qos}?
| | +--rw classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier/id
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
Wen, et al. Expires August 12, 2018 [Page 14]
Internet-Draft L2VPN Service Model February 2018
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw bundling-type? identityref
+--rw default-ce-vlan-id uint32
+--rw site-network-accesses
+--rw site-network-access* [network-access-id]
+--rw network-access-id string
+--rw remote-carrier-name? string
+--rw type? identityref
+--rw (location-flavor)
Wen, et al. Expires August 12, 2018 [Page 15]
Internet-Draft L2VPN Service Model February 2018
| +--:(location)
| | +--rw location-reference?
| | -> ../../../locations/location/
| | location-id
| +--:(device)
| +--rw device-reference?
| -> ../../../devices/device/device-id
+--rw access-diversity {site-diversity}?
| +--rw groups
| | +--rw group* [group-id]
| | +--rw group-id string
| +--rw constraints
| +--rw constraint* [constraint-type]
| +--rw constraint-type identityref
| +--rw target
| +--rw (target-flavor)?
| +--:(id)
| | +--rw group* [group-id]
| | +--rw group-id string
| +--:(all-accesses)
| | +--rw all-other-accesses? empty
| +--:(all-groups)
| +--rw all-other-groups? empty
+--rw bearer
| +--rw requested-type {requested-type}?
| | +--rw type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw connection
| +--rw encapsulation-type? identityref
| +--rw eth-inf-type? identityref
| +--rw tagged-interface
| | +--rw type? identityref
| | +--rw dot1q-vlan-tagged {dot1q}?
| | | +--rw tg-type? identityref
| | | +--rw cvlan-id uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq {qinq}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | | +--rw cvlan-id uint16
| | +--rw qinany {qinany}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | +--rw vxlan {vxlan}?
| | +--rw vni-id uint32
Wen, et al. Expires August 12, 2018 [Page 16]
Internet-Draft L2VPN Service Model February 2018
| | +--rw peer-mode? identityref
| | +--rw peer-list* [peer-ip]
| | +--rw peer-ip inet:ip-address
| +--rw untagged-interface
| | +--rw speed? uint32
| | +--rw mode? neg-mode
| | +--rw phy-mtu? uint32
| | +--rw lldp? boolean
| | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enable? boolean
| | +--rw uni-loop-prevention? boolean
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enable? boolean
| | +--rw mode? neg-mode
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-priority? uint16
| | +--rw micro-bfd {micro-bfd}?
| | | +--rw enable? enumeration
| | | +--rw interval? uint32
| | | +--rw hold-timer? uint32
| | +--rw bfd {bfd}?
| | | +--rw enabled? boolean
| | | +--rw (holdtime)?
| | | +--:(profile)
| | | | +--rw profile-name?
| | | | -> /l2vpn-svc/
| | | | vpn-profiles/
| | | | valid-provider-identifiers/
| | | | bfd-profile-identifier/id
| | | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--rw member-links
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw speed? uint32
| | | +--rw mode? neg-mode
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enable? boolean
| | +--rw flow-control? boolean
| | +--rw lldp? boolean
| +--rw cvlan-id-to-svc-map* [svc-id]
| | +--rw svc-id
| | | -> /l2vpn-svc/vpn-services/vpn-service/
Wen, et al. Expires August 12, 2018 [Page 17]
Internet-Draft L2VPN Service Model February 2018
| | | vpn-id
| | +--rw cvlan-id* [vid]
| | +--rw vid uint16
| +--rw l2cp-control {l2cp-control}?
| | +--rw stp-rstp-mstp? control-mode
| | +--rw pause? control-mode
| | +--rw lacp-lamp? control-mode
| | +--rw link-oam? control-mode
| | +--rw esmc? control-mode
| | +--rw l2cp-802.1x? control-mode
| | +--rw e-lmi? control-mode
| | +--rw lldp? boolean
| | +--rw ptp-peer-delay? control-mode
| | +--rw garp-mrp? control-mode
| +--rw oam {oam}
| +--rw md-name string
| +--rw md-level uint16
| +--rw cfm-802.1-ag* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down? enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw alarm-priority-defect? identityref
| | +--rw ccm-p-bits-pri? ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthethic-loss-measurement? boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
+--rw availability
| +--rw access-priority? uint32
| +--rw (redundancy-mode)?
| +--:(single-active)
| | +--rw single-active? empty
#x27;t' extension is not intended for use in structured data that
already provides separate source and target language identifiers.
For example, this is the case in localization interchange formats
such as XLIFF. In such cases, it would be inappropriate to use
"ja-t-it" for the target language tag because the source language tag
"it" would already be present in the data. Instead, one would use
the language tag "ja".
As noted earlier, it is sometimes necessary to indicate additional
information about a transformation. This additional information is
optionally supplied after the source in a series of one or more
fields, where each field consists of a field separator subtag
followed by one or more non-separator subtags. Each field separator
subtag consists of a single letter followed by a single digit.
A transformation mechanism is an optional field that indicates the
specification used for the transformation, such as "UNGEGN" for the
United Nations Group of Experts on Geographical Names
transliterations and transcriptions. It uses the 'm0' field
separator followed by certain subtags.
For example:
+------------------------------------+------------------------------+
| Language Tag | Description |
+------------------------------------+------------------------------+
| und-Cyrl-t-und-latn-m0-ungegn-2007 | The content is in Cyrillic, |
| | transformed from Latin, |
| | according to a UNGEGN |
| | specification dated 2007. |
+------------------------------------+------------------------------+
The field separator subtags, such as 'm0', were chosen because they
are short, visually distinctive, and cannot occur in a language
subtag (outside of an extension and after 'x'), thus eliminating the
potential for collision or confusion with the source language tag.
The field subtags are defined by Section 3 of Unicode Technical
Standard #35: Unicode Locale Data Markup Language (LDML) [UTS35], the
main specification for the Unicode Common Locale Data Repository
(CLDR) project. That section also defines the parallel 'u' extension
[RFC6067], for which the Unicode Consortium is also the maintaining
authority. As required by BCP 47, subtags follow the language tag
ABNF and other rules for the formation of language tags and subtags,
are restricted to the ASCII letters and digits, are not case
sensitive, and do not exceed eight characters in length.
Davis, et al. Informational [Page 5]
RFC 6497 BCP 47 Extension T February 2012
The LDML specification is available over the Internet and at no cost,
and is available via a royalty-free license at
http://unicode.org/copyright.html. LDML is versioned, and each
version of LDML is numbered, dated, and stable. Extension subtags,
once defined by LDML, are never retracted or substantially changed in
meaning.
The maintaining authority for the 't' extension is the Unicode
Consortium:
+---------------+---------------------------------------------------+
| Item | Value |
+---------------+---------------------------------------------------+
| Name | Unicode Consortium |
| Contact Email | cldr-contact@unicode.org |
| Discussion | cldr-users@unicode.org |
| List Email | |
| URL Location | cldr.unicode.org |
| Specification | Unicode Technical Standard #35 Unicode Locale |
| | Data Markup Language (LDML), |
| | http://unicode.org/reports/tr35/ |
| Section | Section 3 Unicode Language and Locale Identifiers |
+---------------+---------------------------------------------------+
2.2. Structure
The subtags in the 't' extension are of the following form:
t-ext = "t" ; Extension
(("-" lang *("-" field)) ; Source + optional field(s)
/ 1*("-" field)) ; Field(s) only (no source)
lang = language ; BCP 47, with restrictions
["-" script]
["-" region]
*("-" variant)
field = fsep 1*("-" 3*8alphanum) ; With restrictions
fsep = ALPHA DIGIT ; Subtag separators
alphanum = ALPHA / DIGIT
where <language>, <script>, <region>, and <variant> rules are
specified in [BCP47], and <ALPHA> and <DIGIT> rules in [RFC5234].
Davis, et al. Informational [Page 6]
RFC 6497 BCP 47 Extension T February 2012
Description and restrictions:
a. The 't' extension MUST have at least one subtag.
b. The 't' extension normally starts with a source language tag,
which MUST be a regular, canonical language tag as specified by
[BCP47]. Tags described by the 'irregular' production in BCP 47
MUST NOT be used to form the language tag. The source language
tag MAY be omitted: some field values do not require it.
c. There is optionally a sequence of fields, where each field has a
separator followed by a sequence of one or more subtags. Two
identical field separators MUST NOT be present in the language
tag.
d. The order of the fields in a 't' extension is not significant.
The order of subtags within a field is significant. See
Section 2.3 ("Canonicalization").
e. The 't' subtag fields are defined by Section 3 of Unicode
Technical Standard #35: Unicode Locale Data Markup Language
[UTS35].
2.3. Canonicalization
As required by [BCP47], the use of uppercase or lowercase letters is
not significant in the subtags used in this extension. The canonical
form for all subtags in the extension is lowercase, with the fields
ordered by the separators, alphabetically. The order of subtags
within a field is significant, and MUST NOT be changed in the process
of canonicalizing.
Davis, et al. Informational [Page 7]
RFC 6497 BCP 47 Extension T February 2012
2.4. BCP 47 Registration Form
Per RFC 5646, Section 3.7 [BCP47]:
%%
Identifier: t
Description: Specifying Transformed Content
Comments: Subtags for the identification of content that has been
transformed, including but not limited to:
transliteration, transcription, and translation.
Added: 2011-12-16
RFC: RFC 6497
Authority: Unicode Consortium
Contact_Email: cldr-contact@unicode.org
Mailing_List: cldr-users@unicode.org
URL: http://www.unicode.org/Public/cldr/latest/core.zip
%%
2.5. Field Definitions
Assignment of 't' field subtags is determined by the Unicode CLDR
Technical Committee, in accordance with the policies and procedures
in http://www.unicode.org/consortium/tc-procedures.html, and subject
to the Unicode Consortium Policies on
http://www.unicode.org/policies/policies.html.
Assignments that can be made by successive versions of LDML [UTS35]
by the Unicode Consortium without requiring a new RFC include:
o The allocation of new field separator subtags for use after the
't' extension.
o The allocation of subtags valid after a field separator subtag.
o The addition of subtag aliases and descriptions.
o The modification of subtag descriptions.
Changes to the syntax or meaning of the 't' extension would require a
new RFC that obsoletes this document; such an RFC would break
stability, and would thus be contrary to the policies of the Unicode
Consortium.
Davis, et al. Informational [Page 8]Wen, et al. Expires August 12, 2018 [Page 18]
Internet-Draft L2VPN Service Model February 2018
| +--:(all-active)
| +--rw all-active? empty
+--rw vpn-attachment
| +--rw (attachment-flavor)
| +--:(vpn-id)
| | +--rw vpn-id?
| | | -> /l2vpn-svc/vpn-services/
| | | vpn-service/vpn-id
| | +--rw site-role? identityref
| +--:(vpn-policy-id)
| +--rw vpn-policy-id?
| -> ../../../../vpn-policies/
| vpn-policy/vpn-policy-id
+--rw service
| +--rw svc-bandwidth {input-bw}?
| | +--rw bandwidth* [direction type]
| | +--rw direction identityref
| | +--rw type identityref
| | +--rw cos-id? uint8
| | +--rw vpn-id? svc-id
| | +--rw cir uint64
| | +--rw cbs uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? uint64
| +--rw svc-mtu uint16
| +--rw qos {qos}?
| | +--rw classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
Wen, et al. Expires August 12, 2018 [Page 19]
Internet-Draft L2VPN Service Model February 2018
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier/id
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
Wen, et al. Expires August 12, 2018 [Page 20]
Internet-Draft L2VPN Service Model February 2018
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--rw mac-addr-limit
+--rw limit-number? uint16
+--rw time-interval? uint32
+--rw action? identityref
Figure 4
5.1. Features and Augmentation
The model defined in this document implements many features that
allow implementations to be modular. As an example, the layer 2
protocols parameters (Section 5.3.2.2) proposed to the customer may
also be enabled through features. This model also defines some
features for options that are more advanced, such as support for
extranet VPNs (Section 5.2.4), site diversity (Section 5.3), and QoS
(Section 5.10.2).
In addition, as for any YANG model, this service model can be
augmented to implement new behaviors or specific features. For
example, this model defines VXLAN [RFC7348] for Ethernet packet
Encapsulation; if VXLAN Encapsulation does not fulfill all
requirements for describing the service, new options can be added
through augmentation.
5.2. VPN Service Overview
A vpn-service list item contains generic information about the VPN
service. The vpn-id of the vpn-service refers to an internal
reference for this VPN service. This identifier is purely internal
to the organization responsible for the VPN service.
A vpn-service is composed of some characteristics:
Customer information: Used to identify the customer.
VPN Service Type (svc-type): Used to indicate the VPN service Type.
The identifier is a string allowing any encoding for the local
administration of the VPN service.
Cloud Access (cloud-access): All sites in the L2VPN MUST be
authorized to access to the cloud. The cloud-access container
provides parameters for authorization rules. A cloud identifier
Wen, et al. Expires August 12, 2018 [Page 21]
Internet-Draft L2VPN Service Model February 2018
is used to reference the target service. This identifier is local
to each administration.
Service Topology (svc-topo): Used to identify the type of VPN
service topology that is required.
Frame Delivery Service (frame-delivery): Defines the frame delivery
support required for the L2VPN, e.g., multicast delivery, unicast
delivery, or broadcast delivery.
Extranet VPN (extranet-vpns): Indicates that a particular VPN needs
access to resources located in another VPN.
5.2.1. VPN Service Type
The "svc-type" defines the service type for provider provisioned
L2VPNs. The current version of the model supports six flavors:
o Point-to-point Virtual Private Wire Services (VPWS) connecting two
customer Sites;
o Point-to-point or point-to-multipoint Virtual Private Wire
Services (VPWS) connecting a set of customer sites [RFC8214];
o Multipoint Virtual Private LAN services (VPLS) connecting a set of
customer sites;
o Multipoint Virtual Private LAN services (VPLS) connecting one or
more root sites and a set of leave sites, but preventing inter-
leaf sites communication.
o EVPN Service connecting a set of customer sites.
o Ethernet VPN VPWS between two customer sites or a set of customer
sites specified in [RFC8214] and [RFC7432];
Other L2VPN Service Types could be included by augmentation. Note
that an Ethernet Private Line (EPL) service or an Ethernet Virtual
Private Line (EVPL) service is an E-Line service or a point-to-point
Ethernet Virtual Circuit (EVC) service, while an Ethernet Private LAN
(EP-LAN) service or an Ethernet Virtual Private LAN (EVP-LAN) service
is an E-LAN service or a multipoint-to-multipoint EVC service.
5.2.2. VPN Service Topology
The type of VPN service topology can be used for configuration if
needed. The module currently supports: any-to-any; hub-and-spoke
(where hubs can exchange traffic); and hub-and-spoke-disjoint (where
Wen, et al. Expires August 12, 2018 [Page 22]
Internet-Draft L2VPN Service Model February 2018
hubs cannot exchange traffic). New topologies could be added by
augmentation. By default, the any-to-any VPN service topology is
used.
5.2.2.1. Route Target Allocation
A Layer 2 PE-based VPN (such as a VPLS-based VPN, or an EVPN that
uses BGP as its signaling protocol) can be built using route targets
(RTs) as described in [RFC4364] an [RFC7432]. The management system
is expected to automatically allocate a set of RTs upon receiving a
VPN service creation request. How the management system allocates
RTs is out of scope for this document, but multiple ways could be
envisaged, as described in the Section 6.2.1.1 of [RFC8299].
5.2.2.2. Any-to-Any
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
Any-to-Any VPN Service Topology
In the any-to-any VPN service topology, all VPN sites can communicate
with each other without any restrictions. The management system that
receives an any-to-any L2VPN service request through this model is
expected to assign and then configure the MAC-VRF and RTs on the
appropriate PEs. In the any-to-any case, a single RT is generally
required, and every MAC-VRF imports and exports this RT.
5.2.2.3. Hub-and-Spoke
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub-and-Spoke VPN Service Topology
In the Hub-and-Spoke VPN service topology, all Spoke sites can
communicate only with Hub sites, but not with each other. And Hubs
can also communicate with each other. The management system that
receives a Hub-and-Spoke L2VPN service request through this model is
expected to assign and then configure the MAC-VRF and RTs on the
Wen, et al. Expires August 12, 2018 [Page 23]
Internet-Draft L2VPN Service Model February 2018
appropriate PEs. In the Hub-and-Spoke case, two RTs are generally
required (one RT for Hub routes, and one RT for Spoke routes). A Hub
MAC-VRF that connects Hub sites will export Hub routes with the Hub
RT and will import Spoke routes through the Spoke RT. It will also
import the Hub RT to allow Hub-to-Hub communication. A Spoke MAC-VRF
that connects Spoke sites will export Spoke routes with the Spoke RT
and will import Hub routes through the Hub RT.
5.2.2.4. Hub-and-Spoke-Disjoint
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub-and-Spoke-Disjoint VPN Service Topology
In the Hub-and-Spoke-Disjoint VPN service topology, all Spoke sites
can communicate only with Hub sites, but not with each other. And
Hubs cannot communicate with each other. The management system that
receives a Hub-and-Spoke-Disjoint L2VPN service request through this
model is expected to assign and then configure the VRF and RTs on the
appropriate PEs. In the Hub-and-Spoke-Disjoint case, two RTs
arerequired (one RT for Hub routes and one RT for Spoke routes). A
Hub VRF that connects Hub sites will export Hub routes with the Hub
RT and will import Spoke routes through the Spoke RT. A Spoke VRF
that connects Spoke sites will export Spoke routes with the Spoke RT
and will import Hub routes through the Hub RT.
The management system MUST take into account constraints on Hub-and-
Spoke connections, as in the previous case.
Hub-and-Spoke-Disjoint can also be seen as multiple Hub-and-Spoke
VPNs (one per Hub) that share a common set of Spoke sites.
5.2.3. Cloud Access
This model provides cloud access configuration through the cloud-
access container. The usage of cloud-access is targeted for public
cloud and for Internet access. The cloud-access container provides
parameters for authorization rules.
Private cloud access may be addressed through the site container as
described in Section 5.3 with use consistent with sites of type NNI.
RFC 6497 BCP 47 Extension T February 2012
At the time this document was published, one field separator subtag
was specified in [UTS35]: the transform mechanism. That field is
summarized here:
a. The transform mechanism consists of a sequence of subtags
starting with the 'm0' separator followed by one or more
mechanism subtags. Each mechanism subtag has a length of 3 to 8
alphanumeric characters. The sequence as a whole provides an
identification of the specification for the transform, such as
the mechanism subtag 'ungegn' in "und-Cyrl-t-und-latn-m0-ungegn".
In many cases, only one mechanism subtag is necessary, but
multiple subtags MAY be defined in [UTS35] where necessary.
b. Any purely numeric subtag is a representation of a date in the
Gregorian calendar. It MAY occur in any mechanism field, but it
SHOULD only be used where necessary. If it does occur:
* it MUST occur as the final subtag in the field
* it MUST NOT be the only subtag in the field
* it MUST only consist of a sequence of digits of the form YYYY,
YYYYMM, or YYYYMMDD
* it SHOULD be as short as possible
Note: The format is related to that of [RFC3339], but is not the
same. The RFC 3339 full-date won't work because it uses hyphens.
The offset ("Z") is not used because the date is a publication
date (aka 'floating date'). For more information, see
Section 3.3 ("Floating Time") of [W3C-TimeZones].
c. Examples:
* 20110623 represents June 23, 2011.
* There are three dated versions of the UNGEGN transliteration
specification for Hebrew to Latin. They can be represented by
the following language tags:
+ und-Hebr-t-und-latn-m0-ungegn-1972
+ und-Hebr-t-und-latn-m0-ungegn-1977
+ und-Hebr-t-und-latn-m0-ungegn-2007
Davis, et al. Informational [Page 9]
RFC 6497 BCP 47 Extension T February 2012
* Suppose that the BGN transliteration specification for
Cyrillic to Latin had three versions, dated June 11, 1999;
Dec 30, 1999; and May 1, 2011. In that case, the
corresponding first two DATE subtags would require the months
to be distinctive (199906 and 199912), but the last subtag
would only require the year (2011).
d. Some mechanisms may use a versioning system that is not
distinguished by date, or not by date alone. In the latter case,
the version will be of a form specified by [UTS35] for that
mechanism. For example, if the mechanism xxx uses versions of
the form v21a, then a tag could look like "ja-t-it-m0-xxx-v21a".
If there are multiple sub-versions distinguished by date, then a
tag could look like "ja-t-it-m0-xxx-v21a-2007".
A language tag with the 't' extension MAY be used to request a
specific transform of content. In such a case, the recipient SHOULD
return content that corresponds as closely as feasible to the
requested transform, including the specification of the mechanism.
For example, if the request is ja-t-it-m0-xxx-v21a-2007, and the
recipient has content corresponding to both ja-t-it-m0-xxx-v21a and
ja-t-it-m0-xxx-v21b-2009, then the v21a version would be preferred.
As is the case for language matching as discussed in [BCP47],
different implementations MAY have different measures of "closeness".
2.6. Registration of Field Subtags
Registration of transform mechanisms is requested by filing a ticket
at http://cldr.unicode.org/. The proposal in the ticket MUST contain
the following information:
+-------------+-----------------------------------------------------+
| Item | Description |
+-------------+-----------------------------------------------------+
| Subtag | The proposed mechanism subtag (or subtag sequence). |
| Description | A description of the proposed mechanism; that |
| | description MUST be sufficient to distinguish it |
| | from other mechanisms in use. |
| Version | If versioning for the mechanism is not done |
| | according to date, then a description of the |
| | versioning conventions used for the mechanism. |
+-------------+-----------------------------------------------------+
Proposals for clarifications of descriptions or additional aliases
may also be requested by filing a ticket.
Davis, et al. Informational [Page 10]
RFC 6497 BCP 47 Extension T February 2012
The committee MAY define a template for submissions that requests
more information, if it is found that such information would be
useful in evaluating proposals.
2.7. Registration of Additional Fields
In the event that it proves necessary to add an additional field
(such as 'm2'), it can be requested by filing a ticket at
http://cldr.unicode.org/. The proposal in the ticket MUST contain a
full description of the proposed field semantics and subtag syntax,
and MUST conform to the ABNF syntax for "field" presented in
Section 2.2.
2.8. Committee Responses to Registration Proposals
The committee MUST post each proposal publicly within 2 weeks after
reception, to allow for comments. The committee must respond
publicly to each proposal within 4 weeks after reception.
The response MAY:
o request more information or clarification
o accept the proposal, optionally with modifications to the subtag
or description
o reject the proposal, because of significant objections raised on
the mailing list or due to problems with constraints in this
document or in [UTS35]
Accepted tickets result in a new entry in the machine-readable CLDR
BCP 47 data or, in the case of a clarified description, modifications
to the description attribute value for an existing entry.
2.9. Machine-Readable Data
Beginning with CLDR version 1.7.2, machine-readable files are
available listing the data defined for BCP 47 extensions for each
successive version of [UTS35]. The data in these files is used for
testing the validity of subtags for the 't' extension and for the 'u'
extension [RFC6067], for which the Unicode Consortium is also the
maintaining authority. These releases are listed on
http://cldr.unicode.org/index/downloads. Each release has an
associated data directory of the form
"http://unicode.org/Public/cldr/<version>", where "<version>" is
replaced by the release number. For example, for version 1.7.2, the
Davis, et al. Informational [Page 11]
Wen, et al. Expires August 12, 2018 [Page 24]
Internet-Draft L2VPN Service Model February 2018
A cloud identifier is used to reference the target service. This
identifier is local to each administration.
By default, all sites in the L2VPN MUST be authorized to access the
cloud. If restrictions are required, a user MAY configure the
"permit-site" or "deny-site" leaf-list. The permit-site leaf-list
defines the list of sites authorized for cloud access. The deny-site
leaf-list defines the list of sites denied for cloud access. The
model supports both "deny-any-except" and "permit-any-except"
authorization.
How the restrictions will be configured on network elements is out of
scope for this document.
L2VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
In the example above, we configure the global VPN to access the
Internet by creating a cloud-access container pointing to the cloud
identifier for the Internet service. No authorized sites will be
configured, as all sites are required to be able to access the
Internet.
Wen, et al. Expires August 12, 2018 [Page 25]
Internet-Draft L2VPN Service Model February 2018
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
</cloud-access>
</cloud-accesses>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-perservation>true</ce-vlan-cos-perservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
container pointing to the cloud identifier of Cloud 1 will be
created. The permit-site leaf-list will be filled with a reference
to Site 1 and Site 2.
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud1RFC 6497 BCP 47 Extension T February 2012
"core.zip" file is located at
http://unicode.org/Public/cldr/1.7.2/core.zip. The most recent
version is always identified by the version "latest" and can be
accessed by the URL in Section 2.4.
Inside the "core.zip" file, the directory "common/bcp47" contains the
data files listing the valid attributes, keys, and types for each
successive version of [UTS35]. Each data file lists the keys and
types relevant to that topic.
The XML structure lists the keys, such as <key extension="t"
name="m0" description="Transliteration extension mechanism">, with
subelements for the types, such as <type name="ungegn"
description="United Nations Group of Experts on Geographical
Names"/>. The currently defined attributes for the mechanisms
include:
+-------------+-------------------------------+---------------------+
| Attribute | Description | Examples |
+-------------+-------------------------------+---------------------+
| name | The name of the mechanism, | UNGEGN, ALALC |
| | limited to 3-8 characters (or | |
| | sequences of them). | |
| description | A description of the name, | United Nations |
| | with all and only that | Group of Experts on |
| | information necessary to | Geographical Names; |
| | distinguish one name from | American Library |
| | others with which it might be | Association-Library |
| | confused. Descriptions are | of Congress |
| | not intended to provide | |
| | general background | |
| | information. | |
| since | Indicates the first version | 1.9, 2.0.1 |
| | of CLDR where the name | |
| | appears. (Required for new | |
| | items.) | |
| alias | Alternative name of the key | |
| | or type, not limited in | |
| | number of characters. | |
| | Aliases are intended for | |
| | backwards compatibility, not | |
| | to provide all possible | |
| | alternate names or | |
| | designations. (Optional.) | |
+-------------+-------------------------------+---------------------+
The file for the transform extension is "transform.xml". The initial
version of that file contains the following information.
Davis, et al. Informational [Page 12]
RFC 6497 BCP 47 Extension T February 2012
<keyword>
<key extension="t" name="m0" description=
"Transliteration extension mechanism">
<type name="ungegn" description=
"United Nations Group of Experts on Geographical Names"
since="21"/>
<type name="alaloc" description=
"American Library Association-Library of Congress"
since="21"/>
<type name="bgn" description=
"US Board on Geographic Names"
since="21"/>
<type name="mcst" description=
"Korean Ministry of Culture, Sports and Tourism"
since="21"/>
<type name="iso" description=
"International Organization for Standardization"
since="21"/>
<type name="din" description=
"Deutsches Institut fuer Normung"
since="21"/>
<type name="gost" description=
"Euro-Asian Council for Standardization, Metrology
and Certification"
since="21"/>
</key>
</keyword>
To get the version information in XML when working with the data
files, the XML parser must be validating. When the 'core.zip' file
is unzipped, the 'dtd' directory will be at the same level as the
'bcp47&</cloud-identifier>
<permit-site>site1</permit-site>
<permit-site>site2</permit-site>
</cloud-access>
</cloud-accesses>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-perservation>true</ce-vlan-cos-perservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
If all sites except Site 1 require access to Cloud 2, a new cloud-
access container pointing to the cloud identifier of Cloud 2 will be
created. The deny-site leaf-list will be filled with a reference to
Site 1.
Wen, et al. Expires August 12, 2018 [Page 26]
Internet-Draft L2VPN Service Model February 2018
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site>
</cloud-access>
</cloud-accesses>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-perservation>true</ce-vlan-cos-perservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
5.2.4. Extranet VPNs
There are some cases where a particular VPN needs access to resources
(servers, hosts, etc.) that are external. Those resources may be
located in another VPN.
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)
In the figure above, VPN B has some resources on Site B that need to
be made available to some customers/partners. Specifically, VPN A
must be able to access those VPN B resources.
Such a VPN connection scenario can be achieved via a VPN policy as
defined in Section 5.5.2.2. But there are some simple cases where a
particular VPN (VPN A) needs access to all resources in another VPN
(VPN B). The model provides an easy way to set up this connection
using the "extranet-vpns" container.
The extranet-vpns container defines a list of VPNs a particular VPN
wants to access. The extranet-vpns container is used on customer
VPNs accessing extranet resources in another VPN. In the figure
above, in order to provide VPN A with access to VPN B, the extranet-
vpns container needs to be configured under VPN A with an entry
corresponding to VPN B. There is no service configuration
requirement on VPN B.
Wen, et al. Expires August 12, 2018 [Page 27]
Internet-Draft L2VPN Service Model February 2018
Readers should note that even if there is no configuration
requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
in VPN B will gain access to all sites in VPN A.
The "site-role" leaf defines the role of the local VPN sites in the
target extranet VPN service topology. Site roles are defined in
Section 5.4.
In the example below, VPN A accesses VPN B resources through an
extranet connection. A Spoke role is required for VPN A sites, as
sites from VPN A must not be able to communicate with each other
through the extranet VPN connection.
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<svc-topo>hub-spoke</svc-topo>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<svc-topo>any-to-any</svc-topo>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-perservation>true</ce-vlan-cos-perservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
This model does not define how the extranet configuration will be
achieved within the network.
Any VPN interconnection scenario that is more complex (e.g., only
certain parts of sites on VPN A accessing only certain parts of sites
on VPN B) needs to be achieved using a VPN attachment as defined in
Section 5.5.2, and especially a VPN policy as defined in
Section 5.5.2.2.
Wen, et al. Expires August 12, 2018 [Page 28]
Internet-Draft L2VPN Service Model February 2018
5.2.5. Frame Delivery Service
If Frame Delivery Service support is required for an L2VPN, some
global frame delivery parameters are required as input for the
service request. When a CE sends packets that are Broadcast,
Multicast, or Unknown-destination-unicast, replication occurs at the
ingress PE, therefore three frame types are supported.
Users of this model will need to provide the flavors of trees that
will be used by customers within the L2VPN (customer-tree-flavors).
The model defined in this document supports bidirectional, shared,
and source-based trees (and can be augmented to contain other tree
types). Multiple flavors of trees can be supported simultaneously.
Operator network
______________
/ \
| |
| |
Recv -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1
| | \
| | -- Source2
| |
| |
Recv -- Site3 ------- PE3 |
| |
| |
Recv -- Site4 ------- PE4 |
/ | |
Recv -- Site5 ------- | |
| |
| |
\_______________/
Multicast Group to port mappings can be created using the "rp-group-
mappings" leaf. Two group to port mapping methods are supported:
o Static configuration of multicast Ethernet addresses and ports/
interfaces.
o Multicast control protocol based on Layer-2 technology that
signals mappings of multicast addresses to ports/interfaces, such
as Generic Attribute Registration Protocol / GARP Multicast
Registration Protocol (GARP/GMRP) [IEEE-802-1D].
Wen, et al. Expires August 12, 2018 [Page 29]
Internet-Draft L2VPN Service Model February 2018
5.3. Site Overview
A site represents a connection of a customer office to one or more
VPN services. Each site is associated with one or more location.
+-------------+
/ \
+-----| VPN1 |
+------------------+ | \ /
| | | +-------------+
| New York Office |------ (site) -----+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
The "site" container is used for the provider to store information of
detailed implementation arrangements made with either the customer or
with peer operators at each inter-connect location.
We restrict the L2SM to exterior interfaces only, so all internal
interfaces and the underlying topology are outside the scope of L2SM.
Typically, the following characteristics of a site interface handoff
need to be documented as part of the service design:
Unique identifier (site-id): An arbitrary string to uniquely
identify the site within the overall network infrastructure. The
format of site-id is determined by the local administration of the
VPN service.
Device (device): The customer can request one or more customer
premise equipments from the service provider for a particular
site.
Management (management): Defines the model of management for the
site, for example: type, management-transport, address.
Location (location): The site location information to allow easy
retrieval of data about which are the nearest available resources.
Site diversity (site-diversity): Presents some parameters to support
site diversity.
Site Network Accesses (site-network-accesses): Defines the list of
ports to the site and their properties: especially bearer,
connection, and service parameters.
Wen, et al. Expires August 12, 2018 [Page 30]
Internet-Draft L2VPN Service Model February 2018
A site-network-access represents an Ethernet logical connection to a
site. A site may have multiple site-network-accesses.
+------------------+ Site
| |-----------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-----------------------------------
+------------------+
Multiple site-network-accesses are used, for instance, in the case of
multihoming. Some other meshing cases may also include multiple
site-network-accesses.
The site configuration is viewed as a global entity; we assume that
it is mostly the management system's role to split the parameters
between the different elements within the network. For example, in
the case of the site-network-access configuration, the management
system needs to split the parameters between the PE configuration and
the CE configuration.
5.3.1. Devices and Locations
The information in the "location" sub-container under a "site" and in
the "device" container allows easy retrieval of data about which are
the nearest available facilities and can be used for access topology
planning. It may also be used by other network orchestration
components to choose the targeted upstream PE and downstream CE.
Location is expressed in terms of postal information.
A site may be composed of multiple locations. All the locations will
need to be configured as part of the "locations" container and list.
A typical example of a multi-location site is a headquarters office
in a city composed of multiple buildings. Those buildings may be
located in different parts of the city and may be linked by intra-
city fibers (a customer metropolitan area network). In such a case,
when connecting to a VPN service, the customer may ask for
multihoming based on its distributed locations.
Wen, et al. Expires August 12, 2018 [Page 31]
Internet-Draft L2VPN Service Model February 2018
New York Site
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |-----------------------------------
+------------------+
A customer may also request the use of some premises equipment
entities (CEs) from the SP via the "devices" container. Requesting a
CE implies a provider-managed or co-managed model. A particular
device must be ordered to a particular already-configured location.
This would help the SP send the device to the appropriate postal
address. In a multi-location site, a customer may, for example,
request a CE for each location on the site where multihoming must be
implemented. In the figure above, one device may be requested for
the Manhattan location and one other for the Brooklyn location.
By using devices and locations, the user can influence the
multihoming scenario he wants to implement: single CE, dual CE, etc.
5.3.2. Site Network Accesses
The L2SM includes a set of essential physical interface properties
and Ethernet layer characteristics in the "site-network-accesses"
container. Some of these are critical implementation arrangements
that require consent from both customer and provider.
As mentioned earlier, a site may be multihomed. Each logical network
access for a site is defined in the "site-network-accesses"
container. The site-network-access parameter defines how the site is
connected on the network and is split into three main classes of
parameters:
o bearer: defines requirements of the attachment (below Layer 2).
o connection: defines Layer 2 protocol parameters of the attachment.
o availability: defines the site's availability policy. The
availability parameters are defined in Section 5.8.
The site-network-access has a specific type (site-network-access-
type). This document defines two types:
o point-to-point: describes a point-to-point connection between the
SP and the customer.
Wen, et al. Expires August 12, 2018 [Page 32]
Internet-Draft L2VPN Service Model February 2018
o multipoint: describes a multipoint connection between the SP and
the customer.
This site-network-access type may have an impact on the parameters
offered to the customer, e.g., an SP might not offer encryption for
multipoint accesses. It is up to the provider to decide what
parameters are supported for point-to-point and/or multipoint
accesses. Multipoint accesses are out of scope for this document and
some containers defined in the model may require extensions in order
to work properly for multipoint accesses.
5.3.2.1. Bearer
The "bearer" container defines the requirements for the site
attachment to the provider network that are below Layer 3.
The bearer parameters will help to determine the access media to be
used.
5.3.2.2. Connection
The "connection" container defines the layer 2 protocol parameters of
the attachment (e.g.,vlan-id or circuit-id) and provides connectivity
between customer Ethernet switches. Depending on the management
mode, it refers to PE-CE-LAN segment addressing or to CE-to-customer-
LAN segment addressing. In any case, it describes the responsibility
boundary between the provider and the customer. For a customer-
managed site, it refers to the PE-CE-LAN Segment connection. For a
provider-managed site, it refers to the CE-to-LAN Segment connection.
"encapsulation-type" allows the user to select between Ethernet
encapsulation (port-based) or Ethernet VLAN encapsulation (VLAN-
based). All of the allowed Ethernet interface types of service frame
can be listed under "ether-inf-type", e.g., untagged interface,
tagged interface, LAG interface.
Corresponding to "ether-inf-type", the connection container also
presents three sets of link attributes: untagged interface, tagged
interface, or optional LAG interface attributes. These parameters
are essential for the connection to establish properly between the
customer and provider edge devices. The connection container also
defines an L2CP attribute to allow control plane protocol interaction
between the CE devices and PE device.
Wen, et al. Expires August 12, 2018 [Page 33]
Internet-Draft L2VPN Service Model February 2018
5.3.2.2.1. Untagged Interface
For each untagged interface (untagged-interface), there are basic
configuration parameters like interface index and speed, interface
MTU, auto-negotiation and flow-control settings, etc. In addition
and based on mutual agreement, the customer and provider may decide
to enable advanced features, such as LLDP, 802.3AH link OAM, MAC loop
detection/prevention at a UNI. If Loop avoidance is required, the
attribute "uni-loop-prevention" must be set to TRUE.
5.3.2.2.2. Tagged Interface
If the tagged service is enabled on a logical unit on the connection
at the interface, "encapsulation-type" should be specified as the
Ethernet VLAN ecapsulation (if VLAN-based) or VXLAN encapsulation,
and "eth-inf-type&Davis, et al. Informational [Page 13]
RFC 6497 BCP 47 Extension T February 2012
3. Acknowledgements
Thanks to John Emmons and the rest of the Unicode CLDR Technical
Committee for their work in developing the BCP 47 subtags for LDML.
4. IANA Considerations
IANA has inserted the record of Section 2.4 into the Language
Extensions Registry, according to Section 3.7 ("Extensions and the
Extensions Registry") of "Tags for Identifying Languages" [BCP47].
Per Section 5.2 of [BCP47], there might be occasional (rare) requests
by the Unicode Consortium (the "Authority" listed in the record) for
maintenance of this record. Changes that can be submitted to IANA
without the publication of a new RFC are limited to modification of
the Comments, Contact_Email, Mailing_List, and URL fields. Any such
requested changes MUST use the domain 'unicode.org' in any new
addresses or URIs, MUST explicitly cite this document (so that IANA
can reference these requirements), and MUST originate from the
'unicode.org' domain. The domain or authority can only be changed
via a new RFC.
5. Security Considerations
The security considerations for this extension are the same as those
for [BCP47]. See RFC 5646, Section 6, Security Considerations
[BCP47].
6. References
6.1. Normative References
[BCP47] Phillips, A., Ed., and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data
Markup Language (LDML)", February 2012,
<http://www.unicode.org/reports/tr35/>.
Davis, et al. Informational [Page 14]
RFC 6497 BCP 47 Extension T February 2012
6.2. Informative References
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[RFC6067] Davis, M., Phillips, A., and Y. Umaoka, "BCP 47
Extension U", RFC 6067, December 2010.
[W3C-TimeZones]
Phillips, Ed., "W3C Working Group Note: Working with Time
Zones", July 2011,
<http://www.w3.org/TR/2011/NOTE-timezone-20110705/>.
Authors' Addresses
Mark Davis
Google
EMail: mark@macchiato.com
Addison Phillips
Lab126
EMail: addison@lab126.com
Yoshito Umaoka
IBM
EMail: yoshito_umaoka@us.ibm.com
Courtney Falk
Infinite Automata
EMail: court@infiauto.com
Davis, et al. Informational [Page 15]