RELATED ART
A typical optical network for subscriber aggregation is a point-to-multipoint architecture in which a single optical fiber is used to serve multiple customer premises. Such networks may be either passive (multiplexing occurs via optical splitters) or active (multiplexing occurs in an electronic device). As used herein, the term multiplexed optical network (MON) shall refer to an optical network that is either passive or active. Passive optical network (PON) variants have been standardized by the International Telecommunication Union (ITU) and other organizations and are broadly deployed for residential service delivery. Generally, a PON comprises an optical line terminal (OLT) that is coupled to a plurality of optical network terminals (ONTs). The OLT may be positioned at a central office of a telecommunication network or an intermediate point between a central office and a plurality of customer premises, and each ONT may reside at or close to a customer premises. The multiplexed optical network (MON) variant, based on switched Ethernet networks, can be envisioned similarly.
Broadband PON (BPON) is a standard developed for PON traffic, and BPON defines a management interface, referred to as ONT management and control interface (OMCI), between the OLT and ONT. Gigabit PON (GPON) is an evolution of the BPON standard, and OMCI has been expanded and extended for GPON. G.984 describes a broadly encompassing protocol definition of GPON and OMCI, which includes the physical layer media aspects and OAM (PLOAM), link layer aspects, network layer definition of an ONT management control channel (OMCC) as part of the OMCI protocol.
Active Ethernet (AE) is a recent development with many characteristics that mimic GPON, except significantly that the underlying protocol is Ethernet instead of GPON. G.986 creates a very basic set of extensions to the OMCI protocols to specify OMCI transport over Ethernet, using standard Ethernet frames.
However, implementation problems can arise in attempting to use Active Ethernet for the traffic encapsulation of various types of ONT data. For example, for GPON, OMCI defines traffic containers and dedicated GPON encapsulation method (GEM) ports that are unavailable for Ethernet-based protocols, such as Active Ethernet. The lack of such constructs can cause implementation difficulties when attempting to use Active Ethernet to carry traffic across an optical network.
BRIEF DESCRIPTION OF THE DRAWINGS
The disclosure can be better understood with reference to the following drawings. The elements of the drawings are not necessarily to scale relative to each other, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Furthermore, like reference numerals designate corresponding parts throughout the several views.
FIG. 1 is a block diagram illustrating an exemplary embodiment of a communication system having a passive optical network (PON).
FIG. 2 is a block diagram illustrating an exemplary embodiment of a packet transported across a PON, such as is depicted by FIG. 1.
FIG. 3 is a block diagram illustrating an exemplary embodiment of an optical line terminal (OLT), such as is depicted by FIG. 1.
FIG. 4 is a block diagram illustrating an exemplary embodiment of an optical network terminal (ONT), such as is depicted by FIG. 1.
FIG. 5 is a flow chart illustrating an exemplary method for communicating with an OLT, such as is depicted by FIG. 1, for registration and VLAN assignment.
FIG. 6 is a flow chart illustrating an exemplary method for communicating with an OLT, such as is depicted by FIG. 1, for registration and VLAN assignment.
DETAILED DESCRIPTION
The present disclosure pertains to systems and methods for Ethernet-based management of optical networks using ONT management and control interface (OMCI). In one exemplary embodiment, an Ethernet-based protocol, such as Active Ethernet, is used to implement an ONT management and control interface (OMCI) between an optical line terminal (OLT) and a plurality of ONTs of a MON. Further, virtual local area networks (VLANs) are used to separate the traffic carried by the MON. Various techniques are described that permit ONT registration and creation of VLANs for the MON without requiring the use of gigabit PON (GPON) constructs, such as traffic containers (TCONTs) and dedicated GPON encapsulation method (GEM) ports.
FIG. 1 depicts an exemplary embodiment of a communication system 15 having a multiplexed optical network (MON) 21 that is used for a segment between a telecommunication network 22, such as the public switched telephone network (PSTN), and a plurality of customer premises (CP) 25-29. The MON 21 comprises an optical line terminal (OLT) 31 and a plurality of optical network terminals (ONTs) 33-35 that reside at or close to the customer premises 25-29. As shown by FIG. 1, each ONT 33-35 is coupled to one or more customer premises equipment (CPE) 45-49, such as modems, gateways, routers, computers, telephones, fax machines, and/or other equipment at the CP served by the ONT. The MON 21 also comprises a network element 37, such as a switch or multiplexer, that is coupled to the OLT 31 via an optical fiber 38 and to the ONTs 33-35 via optical fibers 39-41.
In the downstream direction, traffic for all of the ONTs 33-35 is carried by the optical fiber 38, and the network element 37 is configured to forward the packets received from the fiber 38 so that each fiber 39-41 only carries traffic destined for the respective ONT 33-35 coupled to it. In the upstream direction, the network element 37 receives packets from the optical fibers 39-41 and transmits such packets across the optical fiber 38 to the OLT 31.
In one exemplary embodiment, the management traffic communicated across the MON 21 is encapsulated according to OMCI protocol thereby creating OMCI packets, and the OMCI packets are encapsulated according to an Ethernet protocol, such as Active Ethernet, to create Ethernet packets, referred to hereafter as “Ethernet management packets” or “EM packets,” that are carried by virtual local area networks (VLANs).
FIG. 2 depicts an exemplary embodiment of an EM packet 52 that is transported across the MON 21. As shown by FIG. 2, the EM packet 52 comprises an OMCI packet 54 encapsulated with Ethernet-based overhead. In this regard, the OMCI packet 54 comprises an OMCI Ethertype (ET) field 56, a type field 57, and a data field 58. The data field 58 includes the data that is carried by the packet 54, and the type field 57 indicates the message type for the packet 54. The ONT 33-35 that transmitted the packet 52 (if the packet 52 is transmitted in the upstream direction) or the ONT 33-35 that is to receive the packet 52 (if the packet 52 is transmitted in the downstream direction) is logically identified by a VLAN tag in a VLAN field 59, which will be described in more detail below.
Appended to the OMCI packet 54 is a media access control (MAC) field 60 and a VLAN field 59. The MAC field 60 includes at least one MAC address, such as a source MAC address identifying the source (e.g., OLT 31 or ONT 33-35) that transmitted the packet 52 and/or a destination MAC address identifying the packet's destination (e.g., OLT 31 or ONT 33-35). The VLAN field 59 includes at least one VLAN tag, such as an S-tag or C-tag, identifying a VLAN that is to carry the packet 52 across the MON 21. Upon receiving a packet 52, the network element 37 is configured to map the packet to at least one port of the network element 37 based on one or more MAC addresses and/or VLAN tags included in the packet's MAC field 60 and/or VLAN field 59. As an example, upon receiving a packet 52 from the fiber 38, the network element 37 may map the packet to each port that is a member of the VLAN identified by a VLAN tag in the packet's VLAN field 59 such that the packet is transmitted across one or more fibers 39-41 that are coupled to such member ports. Techniques for forwarding Ethernet packets carried by VLANs are generally well known and will not be discussed in detail herein.
FIG. 3 depicts an exemplary embodiment of the OLT 31. As shown by FIG. 3, the OLT 31 comprises OLT logic 63 that is configured to generally control the operation of the OLT 31, as will be described in more detail hereafter. The OLT logic 63 can be implemented in software, hardware, firmware, or any combination thereof. In an exemplary embodiment illustrated in FIG. 3, the OLT logic 63 is implemented in software and stored in memory 66 of the OLT 31.
Note that the OLT logic 63, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions. In the context of this document, a “computer-readable medium” can be any means that can contain or store a program for use by or in connection with an instruction execution apparatus.
The exemplary embodiment of the OLT 31 depicted by FIG. 3 comprises at least one conventional processing element 68, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within the OLT 31 via a local interface 69, which can include at least one bus. Furthermore, the OLT 31 comprises a network interface 71 that is coupled to and communicates with the network 22 (FIG. 1), and the OLT 31 comprises an optical interface 72 that is coupled to and communicates with the optical fiber 38 (FIG. 1). As will be described in more detail hereafter, an ONT list 77 and ONT data 78 are stored in the memory 66, and the OLT logic 63 uses the list 77 and data 78 to respectively register and communicate with the ONTs 33-35.
FIG. 4 depicts an exemplary embodiment of an ONT 33. As shown by FIG. 4, the ONT 33 comprises ONT logic 81 that is configured to generally control the operation of the ONT 33, as will be described in more detail hereafter. The ONT logic 81 can be implemented in software, hardware, firmware, or any combination thereof. In an exemplary embodiment illustrated in FIG. 4, the ONT logic 81 is implemented in software and stored in memory 83 of the ONT 33. Note that the ONT logic 81, when implemented in software, can be stored and transported on any computer-readable medium for use by or in connection with an instruction execution apparatus that can fetch and execute instructions.
The exemplary embodiment of the ONT 33 depicted by FIG. 4 comprises at least one conventional processing element 86, such as a digital signal processor (DSP) or a central processing unit (CPU), that communicates to and drives the other elements within the ONT 33 via a local interface 88, which can include at least one bus. Furthermore, the ONT 33 comprises an optical interface 92 that is coupled to and communicates with the respective fiber 39 (FIG. 1) to which it is coupled, and the ONT 33 comprises a CPE interface 95 that is coupled to and communicates with the CPE 45 (FIG. 1) to which it is coupled. ONTs 34 and 35 may be configured similar to the exemplary ONT 33 shown by FIG. 4.
In one exemplary embodiment, each ONT 33-35 is assigned a respective VLAN for at least one data service effectively defining a point-to-point virtual connection between the ONT and OLT 31. Thus, packets carrying data for a given data service with one of the ONTs 33-35 can be communicated between the OLT 31 and such ONT without the packets being received by the other ONTs. Further, for the same ONT 33-35, different VLANs may be assigned to such ONT for different data services. Accordingly, the data for one service can be carried by one VLAN defining a virtual point-to-point connection between the OLT 31 and an ONT 33-35 while data for a different data service can be carried by another VLAN defining another virtual point-to-point connection between the OLT 31 and the same ONT.
In addition, each ONT 33-35 is also assigned a respective VLAN, referred to hereafter as “management VLAN,” to be used for the communication of management information, such as OAM information. Thus, the management traffic for a given ONT 33-35 is carried by a respective management VLAN that defines a virtual point-to-point connection between the ONT and the OLT 31 and functions as an ONT management control channel (OMCC) for the ONT. Accordingly, management traffic, which is carried by EM packets 52, for one ONT 33-35 is not received by the other ONTs. That is, each ONT 33-35 has its own respective management VLAN for communicating management messages, such as OAM, with the OLT 31. While it is feasible for a management VLAN to also carry traffic for data services, the management VLANs in one exemplary embodiment are dedicated for management messages and are not used to carry traffic for data services. Moreover, the data services can be assigned different VLANs, as described above.
There are various types of management functions for which an ONT's management VLAN may be used for communicating messages. As an example, as described above, an ONT's management VLAN may be used for VLAN assignment of the ONT's data services. In addition, the management VLAN may be used to transmit messages for controlling communication across the MON 21. In one exemplary embodiment, the OLT 31 is configured to assign the ONTs 33-35 respective data rates for communicating across the MON 21, thereby controlling the flow of traffic across the MON 21. The OLT 31 may be configured to transmit a management message for assigning a data rate to a respective ONT 33-35 using the ONT's management VLAN. In such an example, the OLT transmits an EM packet 52 in which the data field 58 indicates the data rate assigned to the ONT and the VLAN field 59 includes the VLAN tag of the ONT's management VLAN.
In another example, an ONT 33-35 may transmit a management message indicating an amount of backlog (e.g., number of packets for transmission across the MON 21). In such an example, the ONT 33-35 transmits an EM packet 52 in which the data field 58 has a value indicative of the backlog. Based on the backlogs reported by all of the ONTs 33-35, the OLT 31 may be configured to adjust the ONT data rates to better accommodate the current backlog conditions. There many other types of management messages typically communicated by OLTs and ONTs in conventional MONs, and the management VLANs described herein may be used for communicating such management messages. The management functions typically performed in a conventional MON are generally well known and will not be discussed in detail herein.
Using the VLANs, as described above, effectively provides constructs for transport similar to the TCONTs and GEM ports used in GPON. There are several advantages that such a VLAN-based solution provides. As an example, the higher-layer attributes of G.984.4 managed entities (MEs) can generally be re-used with no or little changes, though some MEs that refer to TCONTs and GEM ports may be re-purposed. Further, Internet protocol (IP) assignment and higher-layer management functions can remain unchanged and operate in the same manner relative to a GPON embodiment. In addition, the similarity in constructs between a VLAN-based embodiment and GPON allows for similar traffic management, and specifically the assignment of VLANs can resemble assignment of GPON GEM ports. The multiplexing/switching performed by the network element 37 can be performed by a relatively simple VLAN-aware switch, and each port on the ONT side may have a dedicated management VLAN. Various other benefits and advantages would be evident to a person of ordinary skill upon reading this disclosure.
However, when implementing a VLAN-based architecture, some problems can arise pertaining to ONT registration and assignment of the management VLANs. In this regard, ONT registration refers to a process of an ONT registering with the OLT in order to become a member of the MON implemented by the OLT. Typically, an OLT requires an ONT to provide a verifiable identifier that is pre-assigned in order to authenticate the ONT before allowing it to communicate across the MON. In GPON, GEM ports can be used to communicate registration messages across the GPON. However, Ethernet protocols, such as Active Ethernet, have no notions of TCONTs or GEM ports making the communication of registration information problematic. In addition, until a valid VLAN is learned by an ONT, communicating registration information to a newly installed ONT may be problematic. Exemplary techniques for registering a newly installed ONT 33-35 and assigning VLANs to such ONT will be described in more detail below.
As shown by FIG. 3, an ONT list 77 is stored in the memory 66 of the OLT 31. Such ONT list 77 includes an identifier, referred to hereafter as an “ONT registration identifier,” for each ONT 33-35 that is to be a member of the MON 21. In one exemplary embodiment, each ONT registration identifier is a unique serial number identifying an ONT 33-35 that is expected to be a member of the MON 21, but other types of ONT identifiers are possible in other embodiments. The list 77 may be provisioned by a network service provider, or the OLT logic 63 may be configured to download the data 77 from a server (not specifically shown) or other source via the network 22 (FIG. 1) or otherwise. Before assigning any VLANs to and/or permitting an ONT 33-35 to join the MON 21, the OLT logic 63 first requires the ONT to provide an ONT registration identifier corresponding to (e.g., matching) one of the ONT registration identifiers stored in the ONT list 77.
When the OLT logic 63 receives an ONT registration identifier corresponding to one in the list 77, the OLT logic 63 authenticates the ONT 33-35 that transmitted the received ONT registration identifier and registers such ONT by assigning it an identifier, referred to hereafter as “ONT network identifier,” that uniquely identifies the ONT relative to the other ONTs registered with the OLT 31. The ONT network identifier is thereafter used by the OLT 31 to identify the VLAN with which to communicate with such ONT 33-35. Note that the ONT network identifier assigned to the ONT may be arbitrarily, algorithmically, or otherwise determined by the OLT logic 63, and if desired, the ONT network identifier may be the same as the ONT registration identifier 100.
When an ONT network identifier is assigned to an ONT 33-35 during registration, the OLT logic 63 stores the newly-assigned ONT network identifier in the ONT data 78 along with the ONT's MAC address. Within such ONT data 78, each ONT network identifier (and corresponding MAC address) are correlated with a VLAN tag for each VLAN assigned to the identified ONT 33-35. As an example, when a management VLAN is assigned to the ONT 33, the ONT data 78 is updated to correlate the ONT network identifier of the ONT 33 with the VLAN tag of such management VLAN. Thereafter, when a management message is to be transmitted to the ONT 33, the OLT logic 63 may use such correlation to identify which management VLAN is to carry the message.
The VLAN correlations in the data 78 may also be used to authenticate packet sources. In this regard, for each packet received by the OLT 31 from the optical fiber 38, the OLT logic 63 is configured to compare the source MAC identifier in the packet to the ONT data 78 in order to authenticate the source of the packet. If the OLT logic 63 cannot find a corresponding (e.g., matching) ONT MAC address in the ONT data 78, then the OLT logic 63 does not authenticate the source of the packet and, therefore, discards the packet. If the OLT logic 63 finds a corresponding ONT MAC address, the OLT logic 63 determines whether such identifier is correlated, by the data 78, with a VLAN tag corresponding to (e.g., matching) a VLAN tag in the packet. If so, the OLT logic 63 authenticates the source of the packet and processes the packet, depending on its contents, as appropriate. If the OLT logic 63 cannot find such a corresponding VLAN tag in the data 78, then the OLT logic 63 does not authenticate the source of the packet and, therefore, discards the packet. Therefore, the OLT logic 63 authenticates a packet only if it is carried by a VLAN assigned to the packet's source ONT 33-35.
One approach to VLAN assignment is to provision each ONT 33-35 and the OLT 31 such that management VLANs are pre-assigned. In such embodiment, each ONT 33-35 is provisioned to store an ONT registration identifier 100 (FIG. 4) unique to the ONT and VLAN data 99 indicating the VLAN tag of its respective management VLAN. Thus, when an ONT 33-35 is installed and powers up, it has been provisioned such that it is aware of the VLAN tag of its respective management VLAN and uses such VLAN to register with the OLT 31. For example, once the ONT 33 powers up, the ONT logic 81 is configured to transmit an EM packet 52 via its respective management VLAN to the OLT 31. Such packet 52 includes the ONT registration identifier 100 (FIG. 4) of the ONT 33, and the OLT 31 registers the ONT 33 based on such identifier 100. In this regard, the OLT logic 63 compares the ONT registration identifier 100 to the ONT list 77 in order to authenticate the ONT 33. If the ONT 33 is authenticated, the OLT logic 63 assigns an ONT network identifier to the ONT 33 and transmits the ONT network identifier to the ONT 33 via the ONT's management VLAN. Thereafter, the OLT 31 and ONT 33 may communicate via the foregoing management VLAN for management purposes, including VLAN assignment for data services supported by the ONT 33.
While the foregoing approach would successfully establish the VLANs, including both management VLANs and VLANs for data services, the provisioning of the ONTs 33-35 with at least the VLAN tags of the management VLANs may be burdensome. Further, human errors in the provisioning process may also create implementation problems and difficulties. To facilitate the provisioning process and help increase the robustness of the MON 21, it would be desirable for VLAN assignment to occur dynamically without requiring the provisioning of a different management VLAN tag for each ONT 33-35.
In one exemplary embodiment, each ONT 33-35 is provisioned to use the same VLAN for registration. This VLAN, which will be referred to hereafter as the “registration VLAN,” is shared by all ONTs 33-35 for registration purposes. Thus, when the ONT 33 is installed and powers up, it is configured to communicate with the OLT 31 via the registration VLAN for registration and assignment of a management VLAN that is dedicated for management messages for the ONT 33. Such management VLAN carries packets only between the OLT 31 and such ONT 33 so that other ONTs 34 and 35 do not have access to the packets carried by the management VLAN of ONT 33. Once the management VLAN of ONT 33 is established, such VLAN is then used to assign other VLANs to the ONT 33 for data services. Such VLANs, like the management VLAN for ONT 33, carry packets only between the OLT 31 and the ONT 33 so that other ONTs 34 and 35 do not have access to the packets carried by the VLANs, although it is possible for at least some of the VLANs to carry packets (e.g., multicast packets) for a plurality of ONTs 33-35, if desired. The other ONTs 34 and 35 are similarly configured to use the registration VLAN in the same manner.
Accordingly, each ONT 33-35 uses the registration VLAN for registration with the OLT 31 and for assignment of its respective management VLAN. Once a management VLAN is assigned to a respective ONT 33-35, the assigned management VLAN is used for management messages, including VLAN assignment for data services. An exemplary operation and configuration of the system 15 for such an embodiment will now be described in more detail below.
In this regard, the VLAN data 99 (FIG. 4) in each ONT 33-35 is provisioned to include a VLAN tag identifying the registration VLAN. The memory 83 also stores an ONT registration identifier 100 that uniquely identifies the ONT. In one exemplary embodiment, the ONT registration identifier 100 is a serial number, but other types of identifiers may be used in other embodiments. In addition, the OLT 31 is provisioned such that the ONT list 77 includes, for each ONT 33-35, an identifier corresponding to (e.g., matching) the ONT registration identifier 100 stored in the respective ONT.
For illustrative purposes, assume that the ONTs 34 and 35 are installed and communicating via the MON 21 when the ONT 33 is newly installed. Upon power up, the ONT logic 81 of the ONT 33 is configured to retrieve from memory 83 the ONT registration identifier 100 and the VLAN tag of the registration VLAN, as shown by block 125 of FIG. 5. The ONT logic 81 is configured to then form a registration message by inserting the ONT registration identifier 100 in the data field 58 (FIG. 2) of an EM packet 52. The ONT logic 81 also inserts the VLAN tag of the registration VLAN into the VLAN field 59 (FIG. 2) and transmits the packet 52 across the respective fiber 39 (FIG. 1) coupled to it, as shown by block 128 of FIG. 5. Since the VLAN field 59 includes the VLAN tag of the registration VLAN, the packet 52 is carried by the registration VLAN across the MON 21 to the OLT 31.
Upon receiving the packet 52, the OLT logic 63 compares the ONT registration identifier 100 in the data field 58 (FIG. 2) to the ONT list 77 in order to authenticate the source of the packet 52. Assuming that the ONT list 77 has been provisioned to include an identifier corresponding to (e.g., matching) the ONT registration identifier 100 from ONT 33, the OLT logic 63 authenticates the source of the packet 52 (i.e., ONT 33 in the instant example) and registers the ONT 33 based on the packet 52. In this regard, the OLT logic 63 updates the ONT data 78 to include an ONT network identifier and MAC address that identify the ONT 33 relative to the other ONTs 34 and 35 of the MON 21. Such ONT network identifier may be the ONT registration identifier 100, but in one exemplary embodiment, the OLT logic 63 assigns the ONT 33 a new ONT network identifier that is then stored in the data 78 and thereafter used for communication with the ONT 33. The OLT logic 63 also assigns a management VLAN to the ONT 33. Such management VLAN is dedicated for management messages (e.g., OAM) between the OLT 31 and the ONT 33. The VLAN tag of the assigned management VLAN, along with the VLAN tags of other VLANs used for communication with the ONT 33, are correlated in the data 78 with at least the ONT network identifier identifying the ONT 33.
Note that there are a variety of techniques that can be used to assign a management VLAN to the ONT 33. As an example, the ONT data 78 may be provisioned to specify the ONT network identifier of the ONT 33 and the VLAN tag of its management VLAN so that the OLT logic 63 simply retrieves such VLAN tag from memory 66 and sends it to the ONT 33. In another example, the OLT logic 63 may arbitrarily or algorithmically determine an unused VLAN tag (i.e., a VLAN tag not currently assigned to the other ONTs 34 and 35 of the MON 21) for the management VLAN of ONT 33. In any event, the VLAN tag for the management VLAN of the ONT 33 is correlated with the ONT network identifier of the ONT 33 in the data 78.
After determining the management VLAN for the ONT 33, the OLT logic 63 is configured to transmit an EM packet 52 indicating the VLAN tag of such VLAN to the ONT 33. Such packet 52 is carried by the registration VLAN shared by the ONTs 33-35. In this regard, the OLT logic 63 inserts the VLAN tag of the registration VLAN into the data field 58 (FIG. 2) and inserts the ONT network identifier of the ONT 33 into the ONT ID field 56 (FIG. 2). The OLT logic 63 also inserts the VLAN tag identifying the registration VLAN into the VLAN field 59 (FIG. 2). Since the VLAN field 59 includes the VLAN tag for the registration VLAN, the packet 52 is carried by the registration VLAN across the MON 21 to the ONT 33.
After receiving such packet 52, the ONT logic 81 reads the ONT ID field 56 to determine the ONT network identifier assigned to it, and the ONT logic 81 also reads the data field 58 to determine the VLAN tag of its management VLAN. Such VLAN tag is thereafter used for the communication of management messages between the ONT 33 and the OLT 31, as shown by blocks 132 and 135 of FIG. 5. As an example, the OLT logic 63 may assign other VLANs to the ONT 33 for data services and communicate the VLAN tags of such VLANs to the ONT 33 in the data field 58 of EM packets 52 carried by the management VLAN assigned to the ONT 33. The tags of such data service VLANs may be provisioned into the ONT data 78 at the OLT 31, and the OLT logic 63 may be configured to transmit the tags to the ONT 33 once the management VLAN is assigned. Alternatively, the OLT logic 63 may arbitrarily or algorithmically select the VLANs to be assigned for data services. If desired, the ONT logic 81 may be configured to transmit, via the newly-assigned management VLAN, an EM packet 52 requesting a VLAN for each service supported by the ONT 33, and the OLT 31 may respond by transmitting the VLAN tags for the data service VLANs to the ONT 33 via EM packets 52 carried by such management VLAN. Yet other techniques for assigning the data service VLANs are possible in other embodiments.
Note that the other ONTs 34 and 35 may be assigned VLANs via similar techniques. That is, each ONT 33-35 uses the shared registration VLAN to register and receive the VLAN tag of its respective management VLAN. Thereafter, each ONT 33-35 uses its respective management VLAN, which is not shared by the other ONTs, for management messaging, including assignment of VLANs for data services.
It should be further noted that it is unnecessary for each ONT 33-35 to be assigned a new management VLAN upon registration, as is described in the exemplary embodiment above. As an example, rather than assigning a respective management VLAN to each ONT 33-35, the ONTs 33-35 may be configured to share the registration VLAN for management messages. To prevent each ONT 33-35 from seeing management traffic pertaining to the other ONTs of the MON 21, the network element 37 may be configured to learn the MAC addresses of the ONTs 33-35 and to make forwarding decisions based on MAC addresses included in the MAC field 60 (FIG. 2) of the EM packets 52.
Thus, if the OLT 31 transmits an EM packet 52 destined for the ONT 33, the OLT logic 63 is configured to insert in the MAC field 60 (FIG. 2) of the packet 52 a destination MAC address identifying the ONT 33, and the OLT logic 63 is configured to insert the VLAN tag of the registration VLAN into the VLAN field 59. Based on such destination MAC address and VLAN tag, the network element 37 is configured to forward the packet 52 only to the fiber 39 coupled to the ONT 33 such that the ONTs 34 and 35 do not receive the packet 52.
In another exemplary embodiment, each ONT 33-35 is configured to attempt registration with the OLT 31 using different VLANs until a VLAN is found that can be assigned to the ONT attempting registration. When the ONT uses such a VLAN to send a registration message, the OLT logic 63 is configured to register the ONT and assign to the ONT the VLAN that carried the registration message. Such VLAN can then be used thereafter as the ONT's management VLAN. An exemplary operation and configuration of the system 15 for such an embodiment will now be described in more detail below.
For illustrative purposes assume that the ONTs 34 and 35 are installed and communicating via the MON 21 and that the ONT 33 is newly installed. Upon power up, the ONT logic 81 of the ONT 33 selects a VLAN tag to be used to attempt registration with the OLT 31, as shown by block 152 of FIG. 6. Using such VLAN tag, the ONT logic 81 transmits an EM packet 52 requesting registration, as shown by block 155. In this regard, the ONT logic 81 is configured to form an EM packet 52 and insert the ONT registration identifier 100 of the ONT 33 in the data field 58 (FIG. 2) of the EM packet 52. The ONT logic 81 also inserts the VLAN tag selected via block 152 into the VLAN field 59 (FIG. 2) and transmits the packet 52 across the respective fiber 39 coupled to it. Since the VLAN field 59 includes the selected VLAN tag, the packet 52 is carried across the MON 21 to the OLT 31 by the VLAN identified by the selected VLAN tag.
Upon receiving the packet, the OLT logic 63 compares the VLAN tag in the VLAN field 59 to the VLAN tags of VLANs assigned to the other ONTs 34 and 35, as indicated by the ONT data 78. If the ONT data 78 indicates that the VLAN tag of the packet 52 corresponds to (e.g., matches) a VLAN tag correlated with an ONT network identifier identifying another ONT 34 or 35, the OLT logic 63 discards the packet 52 and sends no response to the ONT 33. After waiting a predefined amount of time for a response, the ONT logic 81 of the ONT 33 determines in block 159 of FIG. 6 that a response to the registration packet 52 has not been timely received, and selects another VLAN tag that has yet to be used in a registration attempt by the ONT 33. The ONT logic 81 then attempts to register with the OLT 31 using the newly-selected VLAN tag, according to the techniques described above. Accordingly, the ONT logic 81 repetitively attempts registration with different VLAN tags until a VLAN tag is found that results in a timely response from the OLT 31, as will be described in more detail below.
Note that the selection of a VLAN tag in block 152 may be arbitrary or in accordance with any desired algorithm for selecting VLAN tags. As an example, the ONT logic 81 may be configured to select a specified VLAN tag for the first registration attempt and then increment the selected VLAN tag for each unsuccessful registration attempt until a successful registration is achieved.
For illustrative purposes assume that the OLT 31 receives, from the ONT 33, a registration packet 52 having a VLAN tag in the VLAN field 59 that does not match any of the VLAN tags for VLANs assigned to the other ONTs 34 and 35. In such case, the OLT logic 63 compares the ONT registration identifier 100 in the data field 58 of such packet 52 to the ONT list 77 in order to authenticate the source of the packet 52. Assuming that the ONT list 77 has been provisioned to include an identifier corresponding to (e.g., matching) the ONT registration identifier 100, the OLT logic 63 authenticates the source (i.e., ONT 33 in the instant example) of the packet 52 and registers the ONT 33 based on the packet 52, as described above with respect to the embodiment related to FIG. 5. Thus, the OLT logic 63 updates the ONT data 78 to include an ONT network identifier that identifies the ONT 33 relative to the other ONTs 34 and 35 of the MON 21.
In the instant embodiment, the VLAN that carried the registration message resulting in successful registration of the ONT 33 is used as the management VLAN for the ONT 33. Thus, the OLT logic 63 updates the ONT data 78 to correlate the VLAN tag from the VLAN field 59 of the registration packet 52 with the ONT network identifier for the ONT 33. Thereafter, such VLAN tag is used for management messages between the OLT 31 and ONT 33. As an example, upon registering the ONT 33, the OLT logic 63 transmits an EM packet 52 to the ONT 33 for informing the ONT 33 of successful registration. Such packet 52 includes the foregoing VLAN tag in the VLAN field 59 and the MAC address of the ONT 33 in the MAC field 60 (FIG. 2). Upon receiving the packet 52, the ONT logic 81 makes a “yes” determination in block 159 of FIG. 6. Receipt of such packet indicates that successful registration has occurred and the VLAN identified by the VLAN tag in the field 59 has been assigned to the ONT 33 as its management VLAN. Thus, the ONT logic 81 uses such VLAN tag for communication of management messages with the OLT 31, as shown by block 163 of FIG. 6. As an example, using the management VLAN, the OLT 31 and ONT 33 may communicate with one another to assign VLANs for data services supported by the ONT 33, as is described above in the description of the embodiment indicated by FIG. 5.
Note that the other ONTs 34 and 35 may be assigned VLANs via similar techniques. That is, each ONT 33-35 repetitively attempts registration with the OLT 31 using different VLAN tags until one of the attempts results in a successful registration. The VLAN that carried the message associated with the successful registration attempt is assigned the ONT's management VLAN, which is not shared by the other ONTs.
In yet another exemplary embodiment, an independent communication channel is used by the ONTs 33-35 for registration and VLAN assignment, if such an independent communication channel is available. As an example, Link OAM may be used to transmit assigned VLAN tags and ONT identifiers from the OLT 31 to the ONTs 33-35 and to transmit ONT registration identifiers from the ONTs 33-35 to the OLT 31.