Your model doesn't quantify meetings: just the general fact of which teacher met which student, so multiple meetings are not necessarily precluded.
You can change the model is a number of ways: add more verbs to distinguish:
- met-once, vs.
- met-twice vs.
- met-thrice vs.
but you can see this is not a great way to count things.
If you want a count of the meetings, you either need a counter value, or to name the specific meetings so that they can be individually counted.
Either way, you need to make manifest some notion of meetings, not just a has-met relationship.
For the former (just counting), it is a relationship between teacher & student realized with a count value. This is called an association class in UML: it is an association (capturing the relationship) but is represented by a class so it can have attributes, like a count of how many times met. Also sometimes called reification, e.g. in RDF, where we make a noun (concept) for a verb (relationship) so we can attach properties to the noun that represents the relationship. Either way, it makes the relationship something that itself can have attributes, in this case a count value.
For the latter, you would document each meeting, giving each individual meeting an identity of sorts: could be an id, or a start time, something unique.
FWIW, I'm wary of models that prematurely preclude general cardinalities (i.e. require limited cardinalities). Sometimes (not always) one-to-many relationships are premature optimizations on many-to-many relationships. In this case, for example, you'd like to be sure there are business rules that preclude a student from meeting with other teachers, and, that these rules aren't going to be just mollified when there's trouble. You could use many-to-many here (even if never used to capture relationships beyond one-to-many) and perhaps not ever have a (performance) problem.